Systems and methods for secure transaction management and electronic rights protection

ABSTRACT

The present invention provides systems and methods for electronic commerce including secure transaction management and electronic rights protection. Electronic appliances such as computers employed in accordance with the present invention help to ensure that information is accessed and used only in authorized ways, and maintain the integrity, availability, and/or confidentiality of the information. Secure subsystems used with such electronic appliances provide a distributed virtual distribution environment (VDE) that may enforce a secure chain of handling and control, for example, to control and/or meter or otherwise monitor use of electronically stored or disseminated information. Such a virtual distribution environment may be used to protect rights of various participants in electronic commerce and other electronic or electronic-facilitated transactions. Secure distributed and other operating system environments and architectures, employing, for example, secure semiconductor processing arrangements that may establish secure, protected environments at each node. These techniques may be used to support an end-to-end electronic information distribution capability that may be used, for example, utilizing the “electronic highway.”

FIELD(S) OF THE INVENTION(S)

[0001] This invention generally relates to computer and/or electronicsecurity.

[0002] More particularly, this invention relates to systems andtechniques for secure transaction management. This invention alsorelates to computer-based and other electronic appliance-basedtechnologies that help to ensure that information is accessed and/orotherwise used only in authorized ways, and maintains the integrity,availability, and/or confidentiality of such information and processesrelated to such use.

[0003] The invention also relates to systems and methods for protectingrights of various participants in electronic commerce and otherelectronic or electronically-facilitated transactions.

[0004] The invention also relates to secure chains of handling andcontrol for both information content and information employed toregulate the use of such content and consequences of such use. It alsorelates to systems and techniques that manage, including meter and/orlimit and/or otherwise monitor use of electronically stored and/ordisseminated information. The invention particularly relates totransactions, conduct and arrangements that make use of, includingconsequences of use of, such systems and/or techniques.

[0005] The invention also relates to distributed and other operatingsystems, environments and architectures. It also generally relates tosecure architectures, including, for example, tamper-resistanthardware-based processors, that can be used to establish security ateach node of a distributed system.

BACKGROUND AND SUMMARY OF THE INVENTION(S)

[0006] Telecommunications, financial transactions, government processes,business operations, entertainment, and personal business productivityall now depend on electronic appliances. Millions of these electronicappliances have been electronically connected together. Theseinterconnected electronic appliances comprise what is increasinglycalled the “information highway.” Many businesses, academicians, andgovernment leaders are concerned about how to protect the rights ofcitizens and organizations who use this information (also “electronic”or “digital”) highway.

[0007] Electronic Content

[0008] Today, virtually anything that can be represented by words,numbers, graphics, or system of commands and instructions can beformatted into electronic digital information. Television, cable,satellite transmissions, and on-line services transmitted over telephonelines, compete to distribute digital information and entertainment tohomes and businesses. The owners and marketers of this content includesoftware developers, motion picture and recording companies, publishersof books, magazines, and newspapers, and information database providers.The popularization of on-line services has also enabled the individualpersonal computer user to participate as a content provider. It isestimated that the worldwide market for electronic information in 1992was approximately $40 billion and is expected to grow to $200 billion by1997, according to Microsoft Corporation. The present invention canmaterially enhance the revenue of content providers, lower thedistribution costs and the costs for content, better support advertisingand usage information gathering, and better satisfy the needs ofelectronic information users. These improvements can lead to asignificant increase in the amount and variety of electronic informationand the methods by which such information is distributed.

[0009] The inability of conventional products to be shaped to the needsof electronic information providers and users is sharply in contrast tothe present invention. Despite the attention devoted by a cross-sectionof America's largest telecommunications, computer, entertainment andinformation provider companies to some of the problems addressed by thepresent invention, only the present invention provides commerciallysecure, effective solutions for configurable, general purpose electroniccommerce transaction/distribution control systems.

[0010] Controlling Electronic Content

[0011] The present invention provides a new kind of “virtualdistribution environment” (called “VDE” in this document) that secures,administers, and audits electronic information use. VDE also featuresfundamentally important capabilities for managing content that travels“across” the “information highway.” These capabilities comprise a rightsprotection solution that serves all electronic community members. Thesemembers include content creators and distributors, financial serviceproviders, end-users, and others. VDE is the first general purpose,configurable, transaction control/rights protection solution for usersof computers, other electronic appliances, networks, and the informationhighway.

[0012] A fundamental problem for electronic content providers isextending their ability to control the use of proprietary information.Content providers often need to limit use to authorized activities andamounts. Participants in a business model involving, for example,provision of movies and advertising on optical discs may include actors,directors, script and other writers, musicians, studios, publishers,distributors, retailers, advertisers, credit card services, and contentend-users. These participants need the ability to embody their range ofagreements and requirements, including use limitations, into an“extended” agreement comprising an overall electronic business model.This extended agreement is represented by electronic content controlinformation that can automatically enforce agreed upon rights andobligations. Under VDE, such an extended agreement may comprise anelectronic contract involving all business model participants. Such anagreement may alternatively, or in addition, be made up of electronicagreements between subsets of the business model participants. Throughthe use of VDE, electronic commerce can function in the same way astraditional commerce—that is commercial relationships regarding productsand services can be shaped through the negotiation of one or moreagreements between a variety of parties.

[0013] Commercial content providers are concerned with ensuring propercompensation for the use of their electronic information. Electronicdigital information, for example a CD recording, can today be copiedrelatively easily and inexpensively. Similarly, unauthorized copying anduse of software programs deprives rightful owners of billions of dollarsin annual revenue according to the International Intellectual PropertyAlliance. Content providers and distributors have devised a number oflimited function rights protection mechanisms to protect their rights.Authorization passwords and protocols, license servers, “lock/unlock”distribution methods, and non-electronic contractual limitations imposedon users of shrink-wrapped software are a few of the more prevalentcontent protection schemes. In a commercial context, these efforts areinefficient and limited solutions.

[0014] Providers of “electronic currency” have also created protectionsfor their type of content. These systems are not sufficiently adaptable,efficient, nor flexible enough to support the generalized use ofelectronic currency. Furthermore, they do not provide sophisticatedauditing and control configuration capabilities. This means that currentelectronic currency tools lack the sophistication needed for manyreal-world financial business models. VDE provides means for anonymouscurrency and for “conditionally” anonymous currency, wherein currencyrelated activities remain anonymous except under special circumstances.

[0015] VDE Control Capabilities

[0016] VDE allows the owners and distributors of electronic digitalinformation to reliably bill for, and securely control, audit, andbudget the use of, electronic information. It can reliably detect andmonitor the use of commercial information products. VDE uses a widevariety of different electronic information delivery means: including,for example, digital networks, digital broadcast, and physical storagemedia such as optical and magnetic disks. VDE can be used by majornetwork providers, hardware manufacturers, owners of electronicinformation, providers of such information, and clearinghouses thatgather usage information regarding, and bill for the use of, electronicinformation.

[0017] VDE provides comprehensive and configurable transactionmanagement, metering and monitoring technology. It can change howelectronic information products are protected, marketed, packaged, anddistributed. When used, VDE should result in higher revenues forinformation providers and greater user satisfaction and value. Use ofVDE will normally result in lower usage costs, decreased transactioncosts, more efficient access to electronic information, re-usability ofrights protection and other transaction management implementations,greatly improved flexibility in the use of secured information, andgreater standardization of tools and processes for electronictransaction management. VDE can be used to create an adaptableenvironment that fulfills the needs of electronic information owners,distributors, and users; financial clearinghouses; and usage informationanalyzers and resellers.

[0018] Rights and Control Information

[0019] In general, the present invention can be used to protect therights of parties who have:

[0020] (a) proprietary or confidentiality interests in electronicinformation. It can, for example, help ensure that information is usedonly in authorized ways;

[0021] (b) financial interests resulting from the use of electronicallydistributed information. It can help ensure that content providers willbe paid for use of distributed information; and

[0022] (c) interests in electronic credit and electronic currencystorage, communication, and/or use including electronic cash, banking,and purchasing.

[0023] Protecting the rights of electronic community members involves abroad range of technologies. VDE combines these technologies in a waythat creates a “distributed” electronic rights protection “environment.”This environment secures and protects transactions and other processesimportant for rights protection. VDE, for example, provides the abilityto prevent, or impede, interference with and/or observation of,important rights related transactions and processes. VDE, in itspreferred embodiment, uses special purpose tamper resistant SecureProcessing Units (SPUs) to help provide a high level of security for VDEprocesses and information storage and communication.

[0024] The rights protection problems solved by the present inventionare electronic versions of basic societal issues. These issues includeprotecting property rights, protecting privacy rights, properlycompensating people and organizations for their work and risk,protecting money and credit, and generally protecting the security ofinformation. VDE employs a system that uses a common set of processes tomanage rights issues in an efficient, trusted, and cost-effective way.

[0025] VDE can be used to protect the rights of parties who createelectronic content such as, for example: records, games, movies,newspapers, electronic books and reference materials, personalelectronic mail, and confidential records and communications. Theinvention can also be used to protect the rights of parties who provideelectronic products, such as publishers and distributors: the rights ofparties who provide electronic credit and currency to pay for use ofproducts, for example, credit clearinghouses and banks; the rights toprivacy of parties who use electronic content (such as consumers,business people, governments); and the privacy rights of partiesdescribed by electronic information, such as privacy rights related toinformation contained in a medical record, tax record, or personnelrecord.

[0026] In general, the present invention can protect the rights ofparties who have:

[0027] (a) commercial interests in electronically distributedinformation—the present invention can help ensure, for example, thatparties will be paid for use of distributed information in a mannerconsistent with their agreement;

[0028] (b) proprietary and/or confidentiality interests in electronicinformation—the present invention can, for example help ensure that datais used only in authorized ways;

[0029] (c) interests in electronic credit and electronic currencystorage, communication, and/or use—this can include electronic cash,banking, and purchasing; and

[0030] (d) interests in electronic information derived, at least inpart, from use of other electronic information.

[0031] VDE Functional Properties

[0032] VDE is a cost-effective and efficient rights protection solutionthat provides a unified, consistent system for securing and managingtransaction processing. VDE can:

[0033] (a) audit and analyze the use of content,

[0034] (b) ensure that content is used only in authorized ways, and

[0035] (c) allow information regarding content usage to be used only inways approved by content users.

[0036] In addition, VDE.

[0037] (a) is very configurable, modifiable, and re-usable;

[0038] (b) supports a wide range of useful capabilities that may becombined in different ways to accommodate most potential applications;

[0039] (c) operates on a wide variety of electronic appliances rangingfrom hand-held inexpensive devices to large mainframe computers;

[0040] (d) is able to ensure the various rights of a number of differentparties, and a number of different rights protection schemes,simultaneously;

[0041] (e) is able to preserve the rights of parties through a series oftransactions that may occur at different times and different locations;

[0042] (f) is able to flexibly accommodate different ways of securelydelivering information and reporting usage; and

[0043] (g) provides for electronic analogues to “real” money and credit,including anonymous electronic cash, to pay for products and servicesand to support personal (including home) banking and other financialactivities.

[0044] VDE economically and efficiently fulfills the rights protectionneeds of electronic community members. Users of VDE will not requireadditional rights protection systems for different information highwayproducts and rights problems—nor will they be required to install andlearn a new system for each new information highway application.

[0045] VDE provides a unified solution that allows all content creators,providers, and users to employ the same electronic rights protectionsolution. Under authorized circumstances, the participants can freelyexchange content and associated content control sets. This means that auser of VDE may, if allowed, use the same electronic system to work withdifferent kinds of content having different sets of content controlinformation. The content and control information supplied by one groupcan be used by people who normally use content and control informationsupplied by a different group. VDE can allow content to be exchanged“universally” and users of an implementation of the present inventioncan interact electronically without fear of incompatibilities in contentcontrol, violation of rights, or the need to get, install, or learn anew content control system.

[0046] The VDE securely administers transactions that specify protectionof rights. It can protect electronic rights including, for example:

[0047] (a) the property rights of authors of electronic content,

[0048] (b) the commercial rights of distributors of content,

[0049] (c) the rights of any parties who facilitated the distribution ofcontent,

[0050] (d) the privacy rights of users of content,

[0051] (e) the privacy rights of parties portrayed by stored and/ordistributed content, and

[0052] (f) any other rights regarding enforcement of electronicagreements.

[0053] VDE can enable a very broad variety of electronically enforcedcommercial and societal agreements. These agreements can includeelectronically implemented contracts, licenses, laws, regulations, andtax collection.

[0054] Contrast with Traditional Solutions

[0055] Traditional content control mechanisms often require users topurchase more electronic information than the user needs or desires. Forexample, infrequent users of shrink-wrapped software are required topurchase a program at the same price as frequent users, even though theymay receive much less value from their less frequent use. Traditionalsystems do not scale cost according to the extent or character of usageand traditional systems can not attract potential customers who findthat a fixed price is too high. Systems using traditional mechanisms arealso not normally particularly secure. For example, shrink-wrapping doesnot prevent the constant illegal pirating of software once removed fromeither its physical or electronic package.

[0056] Traditional electronic information rights protection systems areoften inflexible and inefficient and may cause a content provider tochoose costly distribution channels that increase a product's price. Ingeneral these mechanisms restrict product pricing, configuration, andmarketing flexibility. These compromises are the result of techniquesfor controlling information which cannot accommodate both differentcontent models and content models which reflect the many, variedrequirements, such as content delivery strategies, of the modelparticipants. This can limit a provider's ability to deliver sufficientoverall value to justify a given product's cost in the eyes of manypotential users. VDE allows content providers and distributors to createapplications and distribution networks that reflect content providers'and users' preferred business models. It offers users a uniquely costeffective and feature rich system that supports the ways providers wantto distribute information and the ways users want to use suchinformation. VDE supports content control models that ensure rights andallow content delivery strategies to be shaped for maximum commercialresults.

[0057] Chain of Handling and Control

[0058] VDE can protect a collection of rights belonging to variousparties having in rights in, or to, electronic information. Thisinformation may be at one location or dispersed across (and/or movingbetween) multiple locations. The information may pass through a “chain”of distributors and a “chain” of users. Usage information may also bereported through one or more “chains” of parties. In general, VDEenables parties that (a) have rights in electronic information, and/or(b) act as direct or indirect agents for parties who have rights inelectronic information, to ensure that the moving, accessing, modifying,or otherwise using of information can be securely controlled by rulesregarding how, when, where, and by whom such activities can beperformed.

[0059] VDE Applications and Software

[0060] VDE is a secure system for regulating electronic conduct andcommerce. Regulation is ensured by control information put in place byone or more parties. These parties may include content providers,electronic hardware manufacturers, financial service providers, orelectronic “infrastructure” companies such as cable ortelecommunications companies. The control information implements “RightsApplications.” Rights applications “run on” the “base software” of thepreferred embodiment. This base software serves as a secure, flexible,general purpose foundation that can accommodate many different rightsapplications, that is, many different business models and theirrespective participant requirements.

[0061] A rights application under VDE is made up of special purposepieces, each of which can correspond to one or more basic electronicprocesses needed for a rights protection environment. These processescan be combined together like building blocks to create electronicagreements that can protect the rights, and may enforce fulfillment ofthe obligations, of electronic information users and providers. One ormore providers of electronic information can easily combine selectedbuilding blocks to create a rights application that is unique to aspecific content distribution model. A group of these pieces canrepresent the capabilities needed to fulfill the agreements betweenusers and providers. These pieces accommodate many requirements ofelectronic commerce including:

[0062] the distribution of permissions to use electronic information;

[0063] the persistence of the control information and sets of controlinformation managing these permissions;

[0064] configurable control set information that can be selected byusers for use with such information;

[0065] data security and usage auditing of electronic information; and

[0066] a secure system for currency, compensation and debit management.

[0067] For electronic commerce, a rights application, under thepreferred embodiment of the present invention, can provide electronicenforcement of the business agreements between all participants. Sincedifferent groups of components can be put together for differentapplications, the present invention can provide electronic controlinformation for a wide variety of different products and markets. Thismeans the present invention can provide a “unified,” efficient, secure,and cost-effective system for electronic commerce and data security.This allows VDE to serve as a single standard for electronic rightsprotection, data security, and electronic currency and banking.

[0068] In a VDE, the separation between a rights application and itsfoundation permits the efficient selection of sets of controlinformation that are appropriate for each of many different types ofapplications and uses. These control sets can reflect both rights ofelectronic community members, as well as obligations (such as providinga history of one's use of a product or paying taxes on one's electronicpurchases). VDE flexibility allows its users to electronically implementand enforce common social and commercial ethics and practices. Byproviding a unified control system, the present invention supports avast range of possible transaction related interests and concerns ofindividuals, communities, businesses, and governments. Due to its opendesign, VDE allows (normally under securely controlled circumstances)applications using technology independently created by users to be“added” to the system and used in conjunction with the foundation of theinvention. In sum, VDE provides a system that can fairly reflect andenforce agreements among parties. It is a broad ranging and systematicsolution that answers the pressing need for a secure, cost-effective,and fair electronic environment.

[0069] VDE Implementation

[0070] The preferred embodiment of the present invention includesvarious tools that enable system designers to directly insert VDEcapabilities into their products. These tools include an ApplicationProgrammer's Interface (“API”) and a Rights Permissioning and ManagementLanguage (“RPML”). The RPML provides comprehensive and detailed controlover the use of the invention's features. VDE also includes certain userinterface subsystems for satisfying the needs of content providers,distributors, and users.

[0071] Information distributed using VDE may take many forms. It may,for example, be “distributed” for use on an individual's own computer,that is the present invention can be used to provide security forlocally stored data. Alternatively, VDE may be used with informationthat is dispersed by authors and/or publishers to one or morerecipients. This information may take many forms including: movies,audio recordings, games, electronic catalog shopping, multimedia,training materials. E-mail and personal documents, object orientedlibraries, software programming resources, and reference/record keepinginformation resources (such as business, medical, legal, scientific,governmental, and consumer databases).

[0072] Electronic rights protection provided by the present inventionwill also provide an important foundation for trusted and efficient homeand commercial banking, electronic credit processes, electronicpurchasing, true or conditionally anonymous electronic cash, and EDI(Electronic Data Interchange). VDE provides important enhancements forimproving data security in organizations by providing “smart”transaction management features that can be far more effective than keyand password based “go/no go” technology.

[0073] VDE normally employs an integration of cryptographic and othersecurity technologies (e.g. encryption, digital signatures, etc.), withother technologies including: component, distributed, and event drivenoperating system technology, and related communications, objectcontainer, database, smart agent, smart card, and semiconductor designtechnologies.

[0074] I. Overview

[0075] A. VDE Solves Important Problems and Fills Critical Needs

[0076] The world is moving towards an integration of electronicinformation appliances. This interconnection of appliances provides afoundation for much greater electronic interaction and the evolution ofelectronic commerce. A variety of capabilities are required to implementan electronic commerce environment. VDE is the first system thatprovides many of these capabilities and therefore solves fundamentalproblems related to electronic dissemination of information.

[0077] Electronic Content

[0078] VDE allows electronic arrangements to be created involving two ormore parties. These agreements can themselves comprise a collection ofagreements between participants in a commercial value chain and/or adata security chain model for handling, auditing, reporting, andpayment. It can provide efficient, reusable, modifiable, and consistentmeans for secure electronic content: distribution, usage control, usagepayment, usage auditing, and usage reporting. Content may, for example,include:

[0079] financial information such as electronic currency and credit;

[0080] commercially distributed electronic information such as referencedatabases, movies, games, and advertising; and

[0081] electronic properties produced by persons and organizations, suchas documents, e-mail, and proprietary database information.

[0082] VDE enables an electronic commerce marketplace that supportsdiffering, competitive business partnerships, agreements, and evolvingoverall business models.

[0083] The features of VDE allow it to function as the first trustedelectronic information control environment that can conform to, andsupport, the bulk of conventional electronic commerce and data securityrequirements. In particular, VDE enables the participants in a businessvalue chain model to create an electronic version of traditionalbusiness agreement terms and conditions and further enables theseparticipants to shape and evolve their electronic commerce models asthey believe appropriate to their business requirements.

[0084] VDE offers an architecture that avoids reflecting specificdistribution biases, administrative and control perspectives, andcontent types. Instead, VDE provides a broad-spectrum, fundamentallyconfigurable and portable, electronic transaction control, distributing,usage, auditing, reporting, and payment operating environment. VDE isnot limited to being an application or application specific toolset thatcovers only a limited subset of electronic interaction activities andparticipants. Rather, VDE supports systems by which such applicationscan be created, modified, and/or reused. As a result, the presentinvention answers pressing, unsolved needs by offering a system thatsupports a standardized control environment which facilitatesinteroperability of electronic appliances, interoperability of contentcontainers, and efficient creation of electronic commerce applicationsand models through the use of a programmable, secure electronictransactions management foundation and reusable and extensibleexecutable components. VDE can support a single electronic “world”within which most forms of electronic transaction activities can bemanaged.

[0085] To answer the developing needs of rights owners and contentproviders and to provide a system that can accommodate the requirementsand agreements of all parties that may be involved in electronicbusiness models (creators, distributors, administrators, users, creditproviders, etc.), VDE supplies an efficient, largely transparent, lowcost and sufficiently secure system (supporting both hardware/softwareand software only models). VDE provides the widely varying securecontrol and administration capabilities required for:

[0086] 1. Different types of electronic content,

[0087] 2. Differing electronic content delivery schemes,

[0088] 3. Differing electronic content usage schemes,

[0089] 4. Different content usage platforms, and

[0090] 5. Differing content marketing and model strategies.

[0091] VDE may be combined with, or integrated into, many separatecomputers and/or other electronic appliances. These appliances typicallyinclude a secure subsystem that can enable control of content use suchas displaying, encrypting, decrypting, printing, copying, saving,extracting, embedding, distributing, auditing usage, etc. The securesubsystem in the preferred embodiment comprises one or more “protectedprocessing environments”, one or more secure databases, and secure“component assemblies” and other items and processes that need to bekept secured. VDE can, for example, securely control electroniccurrency, payments, and/or credit management (including electroniccredit and/or currency receipt, disbursement, encumbering, and/orallocation) using such a “secure subsystem.”

[0092] VDE provides a secure, distributed electronic transactionmanagement system for controlling the distribution and/or other usage ofelectronically provided and/or stored information. VDE controls auditingand reporting of electronic content and/or appliance usage. Users of VDEmay include content creators who apply content usage, usage reporting,and/or usage payment related control information to electronic contentand/or appliances for users such as end-user organizations, individuals,and content and/or appliance distributors. VDE also securely supportsthe payment of money owed (including money owed for content and/orappliance usage) by one or more parties to one or more other parties, inthe form of electronic credit and/or currency.

[0093] Electronic appliances under control of VDE represent VDE ‘nodes’that securely process and control; distributed electronic informationand/or appliance usage, control information formulation, and relatedtransactions. VDE can securely manage the integration of controlinformation provided by two or more parties. As a result, VDE canconstruct an electronic agreement between VDE participants thatrepresent a “negotiation” between, the control requirements of, two ormore parties and enacts terms and conditions of a resulting agreement.VDE ensures the rights of each party to an electronic agreementregarding a wide range of electronic activities related to electronicinformation and/or appliance usage.

[0094] Through use of VDE's control system, traditional contentproviders and users can create electronic relationships that reflecttraditional, non-electronic relationships. They can shape and modifycommercial relationships to accommodate the evolving needs of, andagreements among, themselves. VDE does not require electronic contentproviders and users to modify their business practices and personalpreferences to conform to a metering and control application programthat supports limited, largely fixed functionality. Furthermore, VDEpermits participants to develop business models not feasible withnon-electronic commerce, for example, involving detailed reporting ofcontent usage information, large numbers of distinct transactions athitherto infeasibly low price points, “pass-along” control informationthat is enforced without involvement or advance knowledge of theparticipants, etc.

[0095] The present invention allows content providers and users toformulate their transaction environment to accommodate:

[0096] (1) desired content models, content control models, and contentusage information pathways,

[0097] (2) a complete range of electronic media and distribution means,

[0098] (3) a broad range of pricing, payment, and auditing strategies,

[0099] (4) very flexible privacy and/or reporting models,

[0100] (5) practical and effective security architectures, and

[0101] (6) other administrative procedures that together with steps (1)through (5) can enable most “real world” electronic commerce and datasecurity models, including models unique to the electronic world.

[0102] VDE's transaction management capabilities can enforce:

[0103] (1) privacy rights of users related to information regardingtheir usage of electronic information and/or appliances,

[0104] (2) societal policy such as laws that protect rights of contentusers or require the collection of taxes derived from electronictransaction revenue, and

[0105] (3) the proprietary and/or other rights of parties related toownership of, distribution of, and/or other commercial rights relatedto, electronic information.

[0106] VDE can support “real” commerce in an electronic form, that isthe progressive creation of commercial relationships that form, overtime, a network of interrelated agreements representing a value chainbusiness model. This is achieved in part by enabling content controlinformation to develop through the interaction of (negotiation between)securely created and independently submitted sets of content and/orappliance control information. Different sets of content and/orappliance control information can be submitted by different parties inan electronic business value chain enabled by the present invention.These parties create control information sets through the use of theirrespective VDE installations. Independently, securely deliverable,component based control information allows efficient interaction amongcontrol information sets supplied by different parties.

[0107] VDE permits multiple, separate electronic arrangements to beformed between subsets of parties in a VDE supported electronic valuechain model. These multiple agreements together comprise a VDE valuechain “extended” agreement. VDE allows such constituent electronicagreements, and therefore overall VDE extended agreements, to evolve andreshape over time as additional VDE participants become involved in VDEcontent and/or appliance control information handling. VDE electronicagreements may also be extended as new control information is submittedby existing participants. With VDE, electronic commerce participants arefree to structure and restructure their electronic commerce businessactivities and relationships. As a result, the present invention allowsa competitive electronic commerce marketplace to develop since the useof VDE enables different, widely varying business models using the sameor shared content.

[0108] A significant facet of the present invention's ability to broadlysupport electronic commerce is its ability to securely manageindependently delivered VDE component objects containing controlinformation (normally in the form of VDE objects containing one or moremethods, data, or load module VDE components). This independentlydelivered control information can be integrated with senior and otherpre-existing content control information to securely form derivedcontrol information using the negotiation mechanisms of the presentinvention. All requirements specified by this derived controlinformation must be satisfied before VDE controlled content can beaccessed or otherwise used. This means that, for example, all loadmodules and any mediating data which are listed by the derived controlinformation as required must be available and securely perform theirrequired function. In combination with other aspects of the presentinvention, securely, independently delivered control components allowelectronic commerce participants to freely stipulate their businessrequirements and trade offs. As a result, much as with traditional,non-electronic commerce, the present invention allows electroniccommerce (through a progressive stipulation of various controlrequirements by VDE participants) to evolve into forms of business thatare the most efficient, competitive and useful.

[0109] VDE provides capabilities that rationalize the support ofelectronic commerce and electronic transaction management. Thisrationalization stems from the reusability of control structures anduser interfaces for a wide variety of transaction management relatedactivities. As a result, content usage control, data security,information auditing, and electronic financial activities, can besupported with tools that are reusable, convenient, consistent, andfamiliar. In addition, a rational approach—a transaction/distributioncontrol standard—allows all participants in VDE the same foundation setof hardware control and security, authoring, administration, andmanagement tools to support widely varying types of information,business market model, and/or personal objectives.

[0110] Employing VDE as a general purpose electronictransaction/distribution control system allows users to maintain asingle transaction management control arrangement on each of theircomputers, networks, communication nodes, and/or other electronicappliances. Such a general purpose system can serve the needs of manyelectronic transaction management applications without requiringdistinct, different installations for different purposes. As a result,users of VDE can avoid the confusion and expense and otherinefficiencies of different, limited purpose transaction controlapplications for each different content and/or business model. Forexample, VDE allows content creators to use the same VDE foundationcontrol arrangement for both content authoring and for licensing contentfrom other content creators for inclusion into their products or forother use. Clearinghouses, distributors, content creators, and other VDEusers can all interact, both with the applications running on their VDEinstallations, and with each other, in an entirely consistent manner,using and reusing (largely transparently) the same distributed tools,mechanisms, and consistent user interfaces, regardless of the type ofVDE activity.

[0111] VDE prevents many forms of unauthorized use of electronicinformation, by controlling and auditing (and other administration ofuse) electronically stored and/or disseminated information. Thisincludes, for example, commercially distributed content, electroniccurrency, electronic credit, business transactions (such as EDI),confidential communications, and the like. VDE can further be used toenable commercially provided electronic content to be made available tousers in user defined portions, rather than constraining the user to useportions of content that were “predetermined” by a content creatorand/or other provider for billing purposes.

[0112] VDE, for example, can employ:

[0113] (1) Secure metering means for budgeting and/or auditingelectronic content and/or appliance usage;

[0114] (2) Secure flexible means for enabling compensation and/orbilling rates for content and/or appliance usage, including electroniccredit and/or currency mechanisms for payment means;

[0115] (3) Secure distributed database means for storing control andusage related information (and employing validated compartmentalizationand tagging schemes);

[0116] (4) Secure electronic appliance control means;

[0117] (5) A distributed, secure, “virtual black box” comprised of nodeslocated at every user (including VDE content container creators, othercontent providers, client users, and recipients of secure VDE contentusage information) site. The nodes of said virtual black box normallyinclude a secure subsystem having at least one secure hardware element(a semiconductor element or other hardware module for securely executingVDE control processes), said secure subsystems being distributed atnodes along a pathway of information storage, distribution, payment,usage, and/or auditing. In some embodiments, the functions of saidhardware element, for certain or all nodes, may be performed bysoftware, for example, in host processing environments of electronicappliances;

[0118] (6) Encryption and decryption means;

[0119] (7) Secure communications means employing authentication, digitalsignaturing, and encrypted transmissions. The secure subsystems at saiduser nodes utilize a protocol that establishes and authenticates eachnode's and/or participant's identity, and establishes one or more securehost-to-host encryption keys for communications between the securesubsystems; and

[0120] (8) Secure control means that can allow each VDE installation toperform VDE content authoring (placing content into VDE containers withassociated control information), content distribution, and contentusage; as well as clearinghouse and other administrative and analysisactivities employing content usage information.

[0121] VDE may be used to migrate most non-electronic, traditionalinformation delivery models (including entertainment, referencematerials, catalog shopping, etc.) into an adequately secure digitaldistribution and usage management and payment context. The distributionand financial pathways managed by a VDE arrangement may include:

[0122] content creator(s),

[0123] distributor(s),

[0124] redistributor(s),

[0125] client administrator(s),

[0126] client user(s),

[0127] financial and/or other clearinghouse(s),

[0128] and/or government agencies.

[0129] These distribution and financial pathways may also include:

[0130] advertisers,

[0131] market survey organizations, and/or

[0132] other parties interested in the user usage of informationsecurely delivered and/or stored using VDE.

[0133] Normally, participants in a VDE arrangement will employ the samesecure VDE foundation. Alternate embodiments support VDE arrangementsemploying differing VDE foundations. Such alternate embodiments mayemploy procedures to ensure certain interoperability requirements aremet.

[0134] Secure VDE hardware (also known as SPUs for Secure ProcessingUnits), or VDE installations that use software to substitute for, orcomplement, said hardware (provided by Host Processing Environments(HPEs)), operate in conjunction with secure communications, systemsintegration software, and distributed software control information andsupport structures, to achieve the electronic contract/rights protectionenvironment of the present invention. Together, these VDE componentscomprise a secure, virtual, distributed content and/or appliancecontrol, auditing (and other administration), reporting, and paymentenvironment. In some embodiments and where commercially acceptable,certain VDE participants, such as clearinghouses that normally maintainsufficiently physically secure non-VDE processing environments, may beallowed to employ HPEs rather VDE hardware elements and interoperate,for example, with VDE end-users and content providers. VDE componentstogether comprise a configurable, consistent, secure and “trusted”architecture for distributed, asynchronous control of electronic contentand/or appliance usage. VDE supports a “universe wide” environment forelectronic content delivery, broad dissemination, usage reporting, andusage related payment activities.

[0135] VDE provides generalized configurability. This results, in part,from decomposition of generalized requirements for supporting electroniccommerce and data security into a broad range of constituent “atomic”and higher level components (such as load modules, data elements, andmethods) that may be variously aggregated together to form controlmethods for electronic commerce applications, commercial electronicagreements, and data security arrangements. VDE provides a secureoperating environment employing VDE foundation elements along withsecure independently deliverable VDE components that enable electroniccommerce models and relationships to develop. VDE specifically supportsthe unfolding of distribution models in which content providers, overtime, can expressly agree to, or allow, subsequent content providersand/or users to participate in shaping the control information for, andconsequences of, use of electronic content and/or appliances. A verybroad range of the functional attributes important for supporting simpleto very complex electronic commerce and data security activities aresupported by capabilities of the present invention. As a result, VDEsupports most types of electronic information and/or appliance: usagecontrol (including distribution), security, usage auditing, reporting,other administration, and payment arrangements.

[0136] VDE, in its preferred embodiment, employs object softwaretechnology and uses object technology to form “containers” for deliveryof information that is (at least in part) encrypted or otherwisesecured. These containers may contain electronic content products orother electronic information and some or all of their associatedpermissions (control) information. These container objects may bedistributed along pathways involving content providers and/or contentusers. They may be securely moved among nodes of a Virtual DistributionEnvironment (VDE) arrangement, which nodes operate VDE foundationsoftware and execute control methods to enact electronic informationusage control and/or administration models. The containers deliveredthrough use of the preferred embodiment of the present invention may beemployed both for distributing VDE control instructions (information)and/or to encapsulate and electronically distribute content that hasbeen at least partially secured.

[0137] Content providers who employ the present invention may include,for example, software application and game publishers, databasepublishers, cable, television, and radio broadcasters, electronicshopping vendors, and distributors of information in electronicdocument, book, periodical, e-mail and/or other forms. Corporations,government agencies, and/or individual “end-users” who act as storersof, and/or distributors of, electronic information, may also be VDEcontent providers (in a restricted model, a user provides content onlyto himself and employs VDE to secure his own confidential informationagainst unauthorized use by other parties). Electronic information mayinclude proprietary and/or confidential information for personal orinternal organization use, as well as information, such as softwareapplications, documents, entertainment materials, and/or referenceinformation, which may be provided to other parties. Distribution may beby, for example, physical media delivery, broadcast and/ortelecommunication means, and in the form of “static” files and/orstreams of data. VDE may also be used, for example, for multi-site“real-time” interaction such as teleconferencing, interactive games, oron-line bulletin boards, where restrictions on, and/or auditing of, theuse of all or portions of communicated information is enforced.

[0138] VDE provides important mechanisms for both enforcing commercialagreements and enabling the protection of privacy rights. VDE cansecurely deliver information from one party to another concerning theuse of commercially distributed electronic content. Even if parties areseparated by several “steps” in a chain (pathway) of handling for suchcontent usage information, such information is protected by VDE throughencryption and/or other secure processing. Because of that protection,the accuracy of such information is guaranteed by VDE, and theinformation can be trusted by all parties to whom it is delivered.Furthermore, VDE guarantees that all parties can trust that suchinformation cannot be received by anyone other than the intended,authorized, party(ies) because it is encrypted such that only anauthorized party, or her agents, can decrypt it. Such information mayalso be derived through a secure VDE process at a previouspathway-of-handling location to produce secure VDE reporting informationthat is then communicated securely to its intended recipient's VDEsecure subsystem. Because VDE can deliver such information securely,parties to an electronic agreement need not trust the accuracy ofcommercial usage and/or other information delivered through means otherthan those under control of VDE.

[0139] VDE participants in a commercial value chain can be“commercially” confident (that is, sufficiently confident for commercialpurposes) that the direct (constituent) and/or “extended” electronicagreements they entered into through the use of VDE can be enforcedreliably. These agreements may have both “dynamic” transactionmanagement related aspects, such as content usage control informationenforced through budgeting, metering, and/or reporting of electronicinformation and/or appliance use, and/or they may include “static”electronic assertions, such as an end-user using the system to asserthis or her agreement to pay for services, not to pass to unauthorizedparties electronic information derived from usage of content or systems,and/or agreeing to observe copyright laws. Not only can electronicallyreported transaction related information be trusted under the presentinvention, but payment may be automated by the passing of payment tokensthrough a pathway of payment (which may or may not be the same as apathway for reporting). Such payment can be contained within a VDEcontainer created automatically by a VDE installation in response tocontrol information (located, in the preferred embodiment, in one ormore permissions records) stipulating the “withdrawal” of credit orelectronic currency (such as tokens) from an electronic account (forexample, an account securely maintained by a user's VDE installationsecure subsystem) based upon usage of VDE controlled electronic contentand/or appliances (such as governments, financial credit providers, andusers).

[0140] VDE allows the needs of electronic commerce participants to beserved and it can bind such participants together in a universe wide,trusted commercial network that can be secure enough to support verylarge amounts of commerce. VDE's security and metering secure subsystemcore will be present at all physical locations where VDE related contentis (a) assigned usage related control information (rules and mediatingdata), and/or (b) used. This core can perform security and auditingfunctions (including metering) that operate within a “virtual blackbox,” a collection of distributed, very secure VDE related hardwareinstances that are interconnected by secured information exchange (forexample, telecommunication) processes and distributed database means.VDE further includes highly configurable transaction operating systemtechnology, one or more associated libraries of load modules along withaffiliated data, VDE related administration, data preparation, andanalysis applications, as well as system software designed to enable VDEintegration into host environments and applications. VDE's usage controlinformation, for example, provide for property content and/or appliancerelated: usage authorization, usage auditing (which may include auditreduction), usage billing, usage payment, privacy filtering, reporting,and security related communication and encryption techniques.

[0141] VDE extensively employs methods in the form of software objectsto augment configurability, portability, and security of the VDEenvironment. It also employs a software object architecture for VDEcontent containers that carries protected content and may also carryboth freely available information (e.g, summary, table of contents) andsecured content control information which ensures the performance ofcontrol information. Content control information governs content usageaccording to criteria set by holders of rights to an object's contentsand/or according to parties who otherwise have rights associated withdistributing such content (such as governments, financial creditproviders, and users).

[0142] In part, security is enhanced by object methods employed by thepresent invention because the encryption schemes used to protect anobject can efficiently be further used to protect the associated contentcontrol information (software control information and relevant data)from modification. Said object techniques also enhance portabilitybetween various computer and/or other appliance environments becauseelectronic information in the form of content can be inserted along with(for example, in the same object container as) content controlinformation (for said content) to produce a “published” object. As aresult, various portions of said control information may be specificallyadapted for different environments, such as for diverse computerplatforms and operating systems, and said various portions may all becarried by a VDE container.

[0143] An objective of VDE is supporting a transaction/distributioncontrol standard. Development of such a standard has many obstacles,given the security requirements and related hardware and communicationsissues, widely differing environments, information types, types ofinformation usage, business and/or data security goals, varieties ofparticipants, and properties of delivered information. A significantfeature of VDE accommodates the many, varying distribution and othertransaction variables by, in part, decomposing electronic commerce anddata security functions into generalized capability modules executablewithin a secure hardware SPU and/or corresponding software subsystem andfurther allowing extensive flexibility in assembling, modifying, and/orreplacing, such modules (e.g. load modules and/or methods) inapplications run on a VDE installation foundation. This configurabilityand reconfigurability allows electronic commerce and data securityparticipants to reflect their priorities and requirements through aprocess of iteratively shaping an evolving extended electronic agreement(electronic control model). This shaping can occur as content controlinformation passes from one VDE participant to another and to the extentallowed by “in place” content control information. This process allowsusers of VDE to recast existing control information and/or add newcontrol information as necessary (including the elimination of no longerrequired elements).

[0144] VDE supports trusted (sufficiently secure) electronic informationdistribution and usage control models for both commercial electroniccontent distribution and data security applications. It can beconfigured to meet the diverse requirements of a network of interrelatedparticipants that may include content creators, content distributors,client administrators, end users, and/or clearinghouses and/or othercontent usage information users. These parties may constitute a networkof participants involved in simple to complex electronic contentdissemination, usage control, usage reporting, and/or usage payment.Disseminated content may include both originally provided and VDEgenerated information (such as content usage information) and contentcontrol information may persist through both chains (one or morepathways) of content and content control information handling, as wellas the direct usage of content. The configurability provided by thepresent invention is particularly critical for supporting electroniccommerce, that is enabling businesses to create relationships and evolvestrategies that offer competitive value. Electronic commerce tools thatare not inherently configurable and interoperable will ultimately failto produce products (and services) that meet both basic requirements andevolving needs of most commerce applications.

[0145] VDE's fundamental configurability will allow a broad range ofcompetitive electronic commerce business models to flourish. It allowsbusiness models to be shaped to maximize revenues sources, end-userproduct value, and operating efficiencies. VDE can be employed tosupport multiple, differing models, take advantage of new revenueopportunities, and deliver product configurations most desired by users.Electronic commerce technologies that do not, as the present inventiondoes:

[0146] support a broad range of possible, complementary revenueactivities,

[0147] offer a flexible array of content usage features most desired bycustomers, and

[0148] exploit opportunities for operating efficiencies, will result inproducts that are often intrinsically more costly and less appealing andtherefore less competitive in the marketplace.

[0149] Some of the key factors contributing to the configurabilityintrinsic to the present invention include:

[0150] (a) integration into the fundamental control environment of abroad range of electronic appliances through portable API andprogramming language tools that efficiently support merging of controland auditing capabilities in nearly any electronic appliance environmentwhile maintaining overall system security;

[0151] (b) modular data structures;

[0152] (c) generic content model;

[0153] (d) general modularity and independence of foundationarchitectural components;

[0154] (e) modular security structures;

[0155] (f) variable length and multiple branching chains of control; and

[0156] (g) independent, modular control structures in the form ofexecutable load modules that can be maintained in one or more libraries,and assembled into control methods and models, and where such modelcontrol schemes can “evolve” as control information passes through theVDE installations of participants of a pathway of VDE content controlinformation handling.

[0157] Because of the breadth of issues resolved by the presentinvention, it can provide the emerging “electronic highway” with asingle transaction/distribution control system that can, for a verybroad range of commercial and data security models, ensure againstunauthorized use of confidential and/or proprietary information andcommercial electronic transactions. VDE's electronic transactionmanagement mechanisms can enforce the electronic rights and agreementsof all parties participating in widely varying business and datasecurity models, and this can be efficiently achieved through a singleVDE implementation within each VDE participant's electronic appliance.VDE supports widely varying business and/or data security models thatcan involve a broad range of participants at various “levels” of VDEcontent and/or content control information pathways of handling.Different content control and/or auditing models and agreements may beavailable on the same VDE installation. These models and agreements maycontrol content in relationship to, for example, VDE installationsand/or users in general; certain specific users, installations, classesand/or other groupings of installations and/or users; as well as toelectronic content generally on a given installation, to specificproperties, property portions, classes and/or other groupings ofcontent.

[0158] Distribution using VDE may package both the electronic contentand control information into the same VDE container, and/or may involvethe delivery to an end-user site of different pieces of the same VDEmanaged property from plural separate remote locations and/or in pluralseparate VDE content containers and/or employing plural differentdelivery means. Content control information may be partially or fullydelivered separately from its associated content to a user VDEinstallation in one or more VDE administrative objects. Portions of saidcontrol information may be delivered from one or more sources. Controlinformation may also be available for use by access from a user's VDEinstallation secure sub-system to one or more remote VDE securesub-systems and/or VDE compatible, certified secure remote locations.VDE control processes such as metering, budgeting, decrypting and/orfingerprinting, may as relates to a certain user content usage activity,be performed in a user's local VDE installation secure subsystem, orsaid processes may be divided amongst plural secure subsystems which maybe located in the same user VDE installations and/or in a network serverand in the user installation. For example, a local VDE installation mayperform decryption and save any, or all of, usage metering informationrelated to content and/or electronic appliance usage at such userinstallation could be performed at the server employing secure (e.g.,encrypted) communications between said secure subsystems. Said serverlocation may also be used for near real time, frequent, or more periodicsecure receipt of content usage information from said user installation,with, for example, metered information being maintained only temporarilyat a local user installation.

[0159] Delivery means for VDE managed content may include electronicdata storage means such as optical disks for delivering one portion ofsaid information and broadcasting and/or telecommunicating means forother portions of said information. Electronic data storage means mayinclude magnetic media, optical media, combined magneto-optical systems,flash RAM memory, bubble memory, and/or other memory storage means suchas huge capacity optical storage systems employing holographic,frequency, and/or polarity data storage techniques. Data storage meansmay also employ layered disc techniques, such as the use of generallytransparent and/or translucent materials that pass light through layersof data carrying discs which themselves are physically packaged togetheras one thicker disc. Data carrying locations on such discs may be, atleast in part, opaque.

[0160] VDE supports a general purpose foundation for secure transactionmanagement, including usage control, auditing, reporting, and/orpayment. This general purpose foundation is called “VDE Functions”(“VDEFs”). VDE also supports a collection of “atomic” applicationelements (e.g., load modules) that can be selectively aggregatedtogether to form various VDEF capabilities called control methods andwhich serve as VDEF applications and operating system functions. When ahost operating environment of an electronic appliance includes VDEFcapabilities, it is called a “Rights Operating System” (ROS). VDEF loadmodules, associated data, and methods form a body of information thatfor the purposes of the present invention are called “controlinformation.” VDEF control information may be specifically associatedwith one or more pieces of electronic content and/or it may be employedas a general component of the operating system capabilities of a VDEinstallation.

[0161] VDEF transaction control elements reflect and enact contentspecific and/or more generalized administrative (for example, generaloperating system) control information. VDEF capabilities which cangenerally take the form of applications (application models) that havemore or less configurability which can be shaped by VDE participants,through the use, for example, of VDE templates, to employ specificcapabilities, along, for example, with capability parameter data toreflect the elements of one or more express electronic agreementsbetween VDE participants in regards to the use of electronic contentsuch as commercially distributed products. These control capabilitiesmanage the use of, and/or auditing of use of, electronic content, aswell as reporting information based upon content use, and any paymentfor said use. VDEF capabilities may “evolve” to reflect the requirementsof one or more successive parties who receive or otherwise contribute toa given set of control information. Frequently, for a VDE applicationfor a given content model (such as distribution of entertainment onCD-ROM, content delivery from an Internet repository, or electroniccatalog shopping and advertising, or some combination of the above)participants would be able to securely select from amongst available,alternative control methods and apply related parameter data, whereinsuch selection of control method and/or submission of data wouldconstitute their “contribution” of control information. Alternatively,or in addition, certain control methods that have been expresslycertified as securely interoperable and compatible with said applicationmay be independently submitted by a participant as part of such acontribution. In the most general example, a generally certified loadmodule (certified for a given VDE arrangement and/or content class) maybe used with many or any VDE application that operates in nodes of saidarrangement. These parties, to the extent they are allowed, canindependently and securely add, delete, and/or otherwise modify thespecification of load modules and methods, as well as add, delete orotherwise modify related information.

[0162] Normally the party who creates a VDE content container definesthe general nature of the VDEF capabilities that will and/or may applyto certain electronic information. A VDE content container is an objectthat contains both content (for example, commercially distributedelectronic information products such as computer software programs,movies, electronic publications or reference materials, etc.) andcertain control information related to the use of the object's content.A creating party may make a VDE container available to other parties.Control information delivered by, and/or otherwise available for usewith, VDE content containers comprise (for commercial contentdistribution purposes) VDEF control capabilities (and any associatedparameter data) for electronic content. These capabilities mayconstitute one or more “proposed” electronic agreements (and/oragreement functions available for selection and/or use with parameterdata) that manage the use and/or the consequences of use of such contentand which can enact the terms and conditions of agreements involvingmultiple parties and their various rights and obligations.

[0163] A VDE electronic agreement may be explicit, through a userinterface acceptance by one or more parties, for example by a “junior”party who has received control information from a “senior” party, or itmay be a process amongst equal parties who individually assert theiragreement. Agreement may also result from an automated electronicprocess during which terms and conditions are “evaluated” by certain VDEparticipant control information that assesses whether certain otherelectronic terms and conditions attached to content and/or submitted byanother party are acceptable (do not violate acceptable controlinformation criteria). Such an evaluation process may be quite simple,for example a comparison to ensure compatibility between a portion of,or all senior, control terms and conditions in a table of terms andconditions and the submitted control information of a subsequentparticipant in a pathway of content control information handling, or itmay be a more elaborate process that evaluates the potential outcome of,and/or implements a negotiation process between, two or more sets ofcontrol information submitted by two or more parties. VDE alsoaccommodates a semi-automated process during which one or more VDEparticipants directly, through user interface means, resolve“disagreements” between control information sets by accepting and/orproposing certain control information that may be acceptable to controlinformation representing one or more other parties interests and/orresponds to certain user interface queries for selection of certainalternative choices and/or for certain parameter information, theresponses being adopted if acceptable to applicable senior controlinformation.

[0164] When another party (other than the first applier of rules),perhaps through a negotiation process, accepts, and/or adds to and/orotherwise modifies, “in place” content control information, a VDEagreement between two or more parties related to the use of suchelectronic content may be created (so long as any modifications areconsistent with senior control information). Acceptance of terms andconditions related to certain electronic content may be direct andexpress, or it may be implicit as a result of use of content (depending,for example, on legal requirements, previous exposure to such terms andconditions, and requirements of in place control information).

[0165] VDEF capabilities may be employed, and a VDE agreement may beentered into, by a plurality of parties without the VDEF capabilitiesbeing directly associated with the controlling of certain, specificelectronic information. For example, certain one or more VDEFcapabilities may be present at a VDE installation, and certain VDEagreements may have been entered into during the registration processfor a content distribution application, to be used by such installationfor securely controlling VDE content usage, auditing, reporting and/orpayment. Similarly, a specific VDE participant may enter into a VDE useragreement with a VDE content or electronic appliance provider when theuser and/or her appliance register with such provider as a VDEinstallation and/or user. In such events, VDEF in place controlinformation available to the user VDE installation may require thatcertain VDEF methods are employed, for example in a certain sequence, inorder to be able to use all and/or certain classes, of electroniccontent and/or VDE applications.

[0166] VDE ensures that certain prerequisites necessary for a giventransaction to occur are met. This includes the secure execution of anyrequired load modules and the availability of any required, associateddata. For example, required load modules and data (e.g. in the form of amethod) might specify that sufficient credit from an authorized sourcemust be confirmed as available. It might further require certain one ormore load modules execute as processes at an appropriate time to ensurethat such credit will be used in order to pay for user use of thecontent. A certain content provider might, for example, require meteringthe number of copies made for distribution to employees of a givensoftware program (a portion of the program might be maintained inencrypted form and require the presence of a VDE installation to run).This would require the execution of a metering method for copying of theproperty each time a copy was made for another employee. This sameprovider might also charge fees based on the total number of differentproperties licensed from them by the user and a metering history oftheir licensing of properties might be required to maintain thisinformation.

[0167] VDE provides organization, community, and/or universe wide secureenvironments whose integrity is assured by processes securely controlledin VDE participant user installations (nodes). VDE installations, in thepreferred embodiment, may include both software and tamper resistanthardware semiconductor elements. Such a semiconductor arrangementcomprises, at least in part, special purpose circuitry that has beendesigned to protect against tampering with, or unauthorized observationof, the information and functions used in performing the VDE's controlfunctions. The special purpose secure circuitry provided by the presentinvention includes at least one of: a dedicated semiconductorarrangement known as a Secure Processing Unit (SPU) and/or a standardmicroprocessor, microcontroller, and/or other processing logic thataccommodates the requirements of the present invention and functions asan SPU. VDE's secure hardware may be found incorporated into, forexample, a fax/modem chip or chip pack, I/O controller, video displaycontroller, and/or other available digital processing arrangements. Itis anticipated that portions of the present invention's VDE securehardware capabilities may ultimately be standard design elements ofcentral processing units (CPUs) for computers and various otherelectronic devices.

[0168] Designing VDE capabilities into one or more standardmicroprocessor, microcontroller and/or other digital processingcomponents may materially reduce VDE related hardware costs by employingthe same hardware resources for both the transaction management usescontemplated by the present invention and for other, host electronicappliance functions. This means that a VDE SPU can employ (share)circuitry elements of a “standard” CPU. For example, if a “standard”processor can operate in protected mode and can execute VDE relatedinstructions as a protected activity, then such an embodiment mayprovide sufficient hardware security for a variety of applications andthe expense of a special purpose processor might be avoided. Under onepreferred embodiment of the present invention, certain memory (e.g.,RAM, ROM, NVRAM) is maintained during VDE related instruction processingin a protected mode (for example, as supported by protected modemicroprocessors). This memory is located in the same package as theprocessing logic (e.g. processor). Desirably, the packaging and memoryof such a processor would be designed using security techniques thatenhance its resistance to tampering.

[0169] The degree of overall security of the VDE system is primarilydependent on the degree of tamper resistance and concealment of VDEcontrol process execution and related data storage activities. Employingspecial purpose semiconductor packaging techniques can significantlycontribute to the degree of security. Concealment and tamper-resistancein semiconductor memory (e.g., RAM, ROM, NVRAM) can be achieved, inpart, by employing such memory within an SPU package, by encrypting databefore it is sent to external memory (such as an external REM package)and decrypting encrypted data within the CPU/RAM package before it isexecuted. This process is used for important VDE related data when suchdata is stored on unprotected media, for example, standard host storage,such as random access memory, mass storage, etc. In that event, a VDESPU would encrypt data that results from a secure VDE execution beforesuch data was stored in external memory.

[0170] Summary of Some Important Features Provided by VDE in Accordancewith the Present Invention

[0171] VDE employs a variety of capabilities that serve as a foundationfor a general purpose, sufficiently secure distributed electroniccommerce solution. VDE enables an electronic commerce marketplace thatsupports divergent, competitive business partnerships, agreements, andevolving overall business models. For example, VDE includes featuresthat:

[0172] “sufficiently” impede unauthorized and/or uncompensated use ofelectronic information and/or appliances through the use of securecommunication, storage, and transaction management technologies. VDEsupports a model wide, distributed security implementation which createsa single secure “virtual” transaction processing and information storageenvironment. VDE enables distributed VDE installations to securely storeand communicate information and remotely control the execution processesand the character of use of electronic information at other VDEinstallations and in a wide variety of ways;

[0173] support low-cost, efficient, and effective security architecturesfor transaction control, auditing, reporting, and related communicationsand information storage. VDE may employ tagging related securitytechniques, the time-ageing of encryption keys, the compartmentalizationof both stored control information (including differentially taggingsuch stored information to ensure against substitution and tampering)and distributed content (to, for many content applications, employ oneor more content encryption keys that are unique to the specific VDEinstallation and/or user), private key techniques such as triple DES toencrypt content, public key techniques such as RSA to protectcommunications and to provide the benefits of digital signature andauthentication to securely bind together the nodes of a VDE arrangement,secure processing of important transaction management executable code,and a combining of a small amount of highly secure, hardware protectedstorage space with a much larger “exposed” mass media storage spacestoring secured (normally encrypted and tagged) control and auditinformation. VDE employs special purpose hardware distributed throughoutsome or all locations of a VDE implementation: a) said hardwarecontrolling important elements of: content preparation (such as causingsuch content to be placed in a VDE content container and associatingcontent control information with said content), content and/orelectronic appliance usage auditing, content usage analysis, as well ascontent usage control; and b) said hardware having been designed tosecurely handle processing load module control activities, wherein saidcontrol processing activities may involve a sequence of required controlfactors;

[0174] support dynamic user selection of information subsets of a VDEelectronic information product (VDE controlled content). This contrastswith the constraints of having to use a few high level individual,pre-defined content provider information increments such as beingrequired to select a whole information product or product section inorder to acquire or otherwise use a portion of such product or section.VDE supports metering and usage control over a variety of increments(including “atomic” increments, and combinations of different incrementtypes) that are selected ad hoc by a user and represent a collection ofpre-identified one or more increments (such as one or more blocks of apreidentified nature, e.g., bytes, images, logically related blocks)that form a generally arbitrary, but logical to a user, content“deliverable.” VDE control information (including budgeting, pricing andmetering) can be configured so that it can specifically apply, asappropriate, to ad hoc selection of different, unanticipated variableuser selected aggregations of information increments and pricing levelscan be, at least in part, based on quantities and/or nature of mixedincrement selections (for example, a certain quantity of certain textcould mean associated images might be discounted by 15%; a greaterquantity of text in the “mixed” increment selection might mean theimages are discounted 20%). Such user selected aggregated informationincrements can reflect the actual requirements of a user for informationand is more flexible than being limited to a single, or a few, highlevel, (e.g. product, document, database record) predeterminedincrements. Such high level increments may include quantities ofinformation not desired by the user and as a result be more costly thanthe subset of information needed by the user if such a subset wasavailable. In sum, the present invention allows information contained inelectronic information products to be supplied according to userspecification. Tailoring to user specification allows the presentinvention to provide the greatest value to users, which in turn willgenerate the greatest amount of electronic commerce activity. The user,for example, would be able to define an aggregation of content derivedfrom various portions of an available content product, but which, as adeliverable for use by the user, is an entirely unique aggregatedincrement. The user may, for example, select certain numbers of bytes ofinformation from various portions of an information product, such as areference work, and copy them to disc in unencrypted form and be billedbased on total number of bytes plus a surcharge on the number of“articles” that provided the bytes. A content provider might reasonablycharge less for such a user defined information increment since the userdoes not require all of the content from all of the articles thatcontained desired information. This process of defining a user desiredinformation increment may involve artificial intelligence databasesearch tools that contribute to the location of the most relevantportions of information from an information product and cause theautomatic display to the user of information describing search criteriahits for user selection or the automatic extraction and delivery of suchportions to the user. VDE further supports a wide variety of predefinedincrement types including:

[0175] bytes,

[0176] images,

[0177] content over time for audio or video, or any other increment thatcan be identified by content provider data mapping efforts, such as:

[0178] sentences,

[0179] paragraphs,

[0180] articles,

[0181] database records, and

[0182] byte offsets representing increments of logically relatedinformation.

[0183] VDE supports as many simultaneous predefined increment types asmay be practical for a given type of content and business model.

[0184] securely store at a user's site potentially highly detailedinformation reflective of a user's usage of a variety of differentcontent segment types and employing both inexpensive “exposed” host massstorage for maintaining detailed information in the form of encrypteddata and maintaining summary information for security testing in highlysecure special purpose VDE installation nonvolatile memory (ifavailable).

[0185] support trusted chain of handling capabilities for pathways ofdistributed electronic information and/or for content usage relatedinformation. Such chains may extend, for example, from a contentcreator, to a distributor, a redistributor, a client user, and then mayprovide a pathway for securely reporting the same and/or differing usageinformation to one or more auditors, such as to one or more independentclearinghouses and then back to the content providers, including contentcreators. The same and/or different pathways employed for certaincontent handling, and related content control information and reportinginformation handling, may also be employed as one or more pathways forelectronic payment handling (payment is characterized in the presentinvention as administrative content) for electronic content and/orappliance usage. These pathways are used for conveyance of all orportions of content, and/or content related control information. Contentcreators and other providers can specify the pathways that, partially orfully, must be used to disseminate commercially distributed propertycontent, content control information, payment administrative content,and/or associated usage reporting information. Control informationspecified by content providers may also specify which specific partiesmust or may (including, for example, a group of eligible parties fromwhich a selection may be made) handle conveyed information. It may alsospecify what transmission means (for example telecommunication carriersor media types) and transmission hubs must or may be used.

[0186] support flexible auditing mechanisms, such as employing “bitmapmeters,” that achieve a high degree of efficiency of operation andthroughput and allow, in a practical manner, the retention and readyrecall of information related to previous usage activities and relatedpatterns. This flexibility is adaptable to a wide variety of billing andsecurity control strategies such as:

[0187] upgrade pricing (e.g. suite purchases),

[0188] pricing discounts (including quantity discounts),

[0189] billing related time duration variables such as discounting newpurchases based on the timing of past purchases, and

[0190] security budgets based on quantity of different, logicallyrelated units of electronic information used over an interval of time.

[0191] Use of bitmap meters (including “regular” and “wide” bitmapmeters) to record usage and/or purchase of information, in conjunctionwith other elements of the preferred embodiment of the presentinvention, uniquely supports efficient maintenance of usage history for:(a) rental, (b) flat fee licensing or purchase, (c) licensing orpurchase discounts based upon historical usage variables, and (d)reporting to users in a manner enabling users to determine whether acertain item was acquired, or acquired within a certain time period(without requiring the use of conventional database mechanisms, whichare highly inefficient for these applications). Bitmap meter methodsrecord activities associated with electronic appliances, properties,objects, or portions thereof, and/or administrative activities that areindependent of specific properties, objects, etc., performed by a userand/or electronic appliance such that a content and/or applianceprovider and/or controller of an administrative activity can determinewhether a certain activity has occurred at some point, or during acertain period, in the past (for example, certain use of a commercialelectronic content product and/or appliance). Such determinations canthen be used as part of pricing and/or control strategies of a contentand/or appliance provider, and/or controller of an administrativeactivity. For example, the content provider may choose to charge onlyonce for access to a portion of a property, regardless of the number oftimes that portion of the property is accessed by a user.

[0192] support “launchable” content, that is content that can beprovided by a content provider to an end-user, who can then copy or passalong the content to other end-user parties without requiring the directparticipation of a content provider to register and/or otherwiseinitialize the content for use. This content goes “out of (thetraditional distribution) channel” in the form of a “traveling object.”Traveling objects are containers that securely carry at least somepermissions information and/or methods that are required for their use(such methods need not be carried by traveling objects if the requiredmethods will be available at, or directly available to, a destinationVDE installation). Certain travelling objects may be used at some or allVDE installations of a given VDE arrangement since they can makeavailable the content control information necessary for content usewithout requiring the involvement of a commercial VDE value chainparticipant or data security administrator (e.g. a control officer ornetwork administrator). As long as traveling object control informationrequirements are available at the user VDE installation secure subsystem(such as the presence of a sufficient quantity of financial credit froman authorized credit provider), at least some travelling object contentmay be used by a receiving party without the need to establish aconnection with a remote VDE authority (until, for example, budgets areexhausted or a time content usage reporting interval has occurred).Traveling objects can travel “out-of-channel,” allowing, for example, auser to give a copy of a traveling object whose content is a softwareprogram, a movie or a game, to a neighbor, the neighbor being able touse the traveling object if appropriate credit (e.g. an electronicclearinghouse account from a clearinghouse such as VISA or AT&T) isavailable. Similarly, electronic information that is generally availableon an Internet, or a similar network, repository might be provided inthe form of a traveling object that can be downloaded and subsequentlycopied by the initial downloader and then passed along to other partieswho may pass the object on to additional parties.

[0193] provide very flexible and extensible user identificationaccording to individuals, installations, by groups such as classes, andby function and hierarchical identification employing a hierarchy oflevels of client identification (for example, client organization ID,client department ID, client network ID, client project ID, and clientemployee ID, or any appropriate subset of the above).

[0194] provide a general purpose, secure, component based contentcontrol and distribution system that functions as a foundationtransaction operating system environment that employs executable codepieces crafted for transaction control and auditing. These code piecescan be reused to optimize efficiency in creation and operation oftrusted, distributed transaction management arrangements. VDE supportsproviding such executable code in the form of “atomic” load modules andassociated data. Many such load modules are inherently configurable,aggregatable, portable, and extensible and singularly, or in combination(along with associated data), run as control methods under the VDEtransaction operating environment. VDE can satisfy the requirements ofwidely differing electronic commerce and data security applications by,in part, employing this general purpose transaction managementfoundation to securely process VDE transaction related control methods.Control methods are created primarily through the use of one or more ofsaid executable, reusable load module code pieces (normally in the formof executable object components) and associated data. The componentnature of control methods allows the present invention to efficientlyoperate as a highly configurable content control system. Under thepresent invention, content control models can be iteratively andasynchronously shaped, and otherwise updated to accommodate the needs ofVDE participants to the extent that such shaping and otherwise updatingconforms to constraints applied by a VDE application, if any (e.g.,whether new component assemblies are accepted and, if so, whatcertification requirements exist for such component assemblies orwhether any or certain participants may shape any or certain controlinformation by selection amongst optional control information(permissions record) control methods. This iterative (or concurrent)multiple participant process occurs as a result of the submission anduse of secure, control information components (executable code such asload modules and/or methods, and/or associated data). These componentsmay be contributed independently by secure communication between eachcontrol information influencing VDE participant's VDE installation andmay require certification for use with a given application, where suchcertification was provided by a certification service manager for theVDE arrangement who ensures secure interoperability and/or reliability(e.g., bug control resulting from interaction) between appliances andsubmitted control methods. The transaction management control functionsof a VDE electronic appliance transaction operating environment interactwith non-secure transaction management operating system functions toproperly direct transaction processes and data related to electronicinformation security, usage control, auditing, and usage reporting. VDEprovides the capability to manages resources related to secure VDEcontent and/or appliance control information execution and data storage.

[0195] facilitate creation of application and/or system functionalityunder VDE and to facilitate integration into electronic applianceenvironments of load modules and methods created under the presentinvention. To achieve this, VDE employs an Application Programmer'sInterface (API) and/or a transaction operating system (such as a ROS)programming language with incorporated functions, both of which supportthe use of capabilities and can be used to efficiently and tightlyintegrate VDE functionality into commercial and user applications.

[0196] support user interaction through: (a) “Pop-Up” applicationswhich, for example, provide messages to users and enable users to takespecific actions such as approving a transaction, (b) stand-alone VDEapplications that provide administrative environments for useractivities such as: end-user preference specifications for limiting theprice per transaction, unit of time, and/or session, for accessinghistory information concerning previous transactions, for reviewingfinancial information such as budgets, expenditures (e.g. detailedand/or summary) and usage analysis information, and (c) VDE awareapplications which, as a result of the use of a VDE API and/or atransaction management (for example, ROS based) programming languageembeds VDE “awareness” into commercial or internal software (applicationprograms, games, etc.) so that VDE user control information and servicesare seamlessly integrated into such software and can be directlyaccessed by a user since the underlying functionality has beenintegrated into the commercial software's native design. For example, ina VDE aware word processor application, a user may be able to “print” adocument into a VDE content container object, applying specific controlinformation by selecting from amongst a series of different menutemplates for different purposes (for example, a confidential memotemplate for internal organization purposes may restrict the ability to“keep,” that is to make an electronic copy of the memo).

[0197] employ “templates” to ease the process of configuringcapabilities of the present invention as they relate to specificindustries or businesses. Templates are applications or applicationadd-ons under the present invention. Templates support the efficientspecification and/or manipulation of criteria related to specificcontent types, distribution approaches, pricing mechanisms, userinteractions with content and/or administrative activities, and/or thelike. Given the very large range of capabilities and configurationssupported by the present invention, reducing the range of configurationopportunities to a manageable subset particularly appropriate for agiven business model allows the full configurable power of the presentinvention to be easily employed by “typical” users who would beotherwise burdened with complex programming and/or configuration designresponsibilities template applications can also help ensure that VDErelated processes are secure and optimally bug free by reducing therisks associated with the contribution of independently developed loadmodules, including unpredictable aspects of code interaction betweenindependent modules and applications, as well as security risksassociated with possible presence of viruses in such modules. VDE,through the use of templates, reduces typical user configurationresponsibilities to an appropriately focused set of activities includingselection of method types (e.g. functionality) through menu choices suchas multiple choice, icon selection, and/or prompting for methodparameter data (such as identification information, prices, budgetlimits, dates, periods of time, access rights to specific content, etc.)that supply appropriate and/or necessary data for control informationpurposes. By limiting the typical (non-programming) user to a limitedsubset of configuration activities whose general configurationenvironment (template) has been preset to reflect general requirementscorresponding to that user, or a content or other business model canvery substantially limit difficulties associated with contentcontainerization (including placing initial control information oncontent), distribution, client administration, electronic agreementimplementation, end-user interaction, and clearinghouse activities,including associated interoperability problems (such as conflictsresulting from security, operating system, and/or certificationincompatibilities). Use of appropriate VDE templates can assure usersthat their activities related to content VDE containerization,contribution of other control information, communications, encryptiontechniques and/or keys, etc. will be in compliance with specificationsfor their distributed VDE arrangement. VDE templates constitute presetconfigurations that can normally be reconfigurable to allow for newand/or modified templates that reflect adaptation into new industries asthey evolve or to reflect the evolution or other change of an existingindustry. For example, the template concept may be used to provideindividual, overall frameworks for organizations and individuals thatcreate, modify, market, distribute, consume, and/or otherwise usemovies, audio recordings and live performances, magazines, telephonybased retail sales, catalogs, computer software, information data bases,multimedia, commercial communications, advertisements, market surveys,infomercials, games, CAD/CAM services for numerically controlledmachines, and the like. As the content surrounding these templateschanges or evolves, template applications provided under the presentinvention may be modified to meet these changes for broad use, or formore focused activities. A given VDE participant may have a plurality oftemplates available for different tasks. A party that places content inits initial VDE container may have a variety of different, configurabletemplates depending on the type of content and/or business model relatedto the content. An end-user may have different configurable templatesthat can be applied to different document types (e-mail, secure internaldocuments, database records, etc.) and/or subsets of users (applyingdiffering general sets of control information to different bodies ofusers, for example, selecting a list of users who may, under certainpreset criteria, use a certain document). Of course, templates may,under certain circumstances have fixed control information and notprovide for user selections or parameter data entry.

[0198] support plural, different control models regulating the useand/or auditing of either the same specific copy of electronicinformation content and/or differently regulating different copies(occurrences) of the same electronic information content. Differingmodels for billing, auditing, and security can be applied to the samepiece of electronic information content and such differing sets ofcontrol information may employ, for control purposes, the same, ordiffering, granularities of electronic information control increments.This includes supporting variable control information for budgeting andauditing usage as applied to a variety of predefined increments ofelectronic information, including employing a variety of differentbudgets and/or metering increments for a given electronic informationdeliverable for: billing units of measure, credit limit, security budgetlimit and security content metering increments, and/or market surveyingand customer profiling content metering increments. For example, aCD-ROM disk with a database of scientific articles might be in partbilled according to a formula based on the number of bytes decrypted,number of articles containing said bytes decrypted, whole a securitybudget might limit the use of said database to no more than 5% of thedatabase per month for users on the wide area network it is installedon.

[0199] provide mechanisms to persistently maintain trusted content usageand reporting control information through both a sufficiently securechain of handling of content and content control information and throughvarious forms of usage of such content wherein said persistence ofcontrol may survive such use. Persistence of control includes theability to extract information from a VDE container object by creating anew container whose contents are at least in part secured and thatcontains both the extracted content and at least a portion of thecontrol information which control information of the original containerand/or are at least in part produced by control information of theoriginal container for this purpose and/or VDE installation controlinformation stipulates should persist and/or control usage of content inthe newly formed container. Such control information can continue tomanage usage of container content if the container is “embedded” intoanother VDE managed object, such as an object which contains pluralembedded VDE containers, each of which contains content derived(extracted) from a different source.

[0200] enables users, other value chain participants (such asclearinghouses and government agencies), and/or user organizations, tospecify preferences or requirements related to their use of electroniccontent and/or appliances. Content users, such as end-user customersusing commercially distributed content (games, information resources,software programs, etc.), can define, if allowed by senior controlinformation, budgets, and/or other control information, to manage theirown internal use of content. Uses include, for example, a user setting alimit on the price for electronic documents that the user is willing topay without prior express user authorization, and the user establishingthe character of metering information he or she is willing to allow tobe collected (privacy protection). This includes providing the means forcontent users to protect the privacy of information derived from theiruse of a VDE installation and content and/or appliance usage auditing.In particular, VDE can prevent information related to a participant'susage of electronic content from being provided to other parties withoutthe participant's tacit or explicit agreement.

[0201] provide mechanisms that allow control information to “evolve” andbe modified according, at least in part, to independently, securelydelivered further control information. Said control information mayinclude executable code (e.g., load modules) that has been certified asacceptable (e.g., reliable and trusted) for use with a specific VDEapplication, class of applications, and/or a VDE distributedarrangement. This modification (evolution) of control information canoccur upon content control information (load modules and any associateddata) circulating to one or more VDE participants in a pathway ofhandling of control information, or it may occur upon controlinformation being received from a VDE participant. Handlers in a pathwayof handling of content control information, to the extent each isauthorized, can establish, modify, and/or contribute to, permission,auditing, payment, and reporting control information related tocontrolling, analyzing, paying for, and/or reporting usage of,electronic content and/or appliances (for example, as related to usageof VDE controlled property content). Independently delivered (from anindependent source which is independent except in regards tocertification), at least in part secure, control information can beemployed to securely modify content control information when contentcontrol information has flowed from one party to another party in asequence of VDE content control information handling. This modificationemploys, for example, one or more VDE component assemblies beingsecurely processed in a VDE secure subsystem. In an alternateembodiment, control information may be modified by a senior partythrough use of their VDE installation secure sub-system after receivingsubmitted, at least in part secured, control information from a “junior”party, normally in the form of a VDE administrative object. Controlinformation passing along VDE pathways can represent a mixed controlset, in that it may include: control information that persisted througha sequence of control information handlers, other control informationthat was allowed to be modified, and further control informationrepresenting new control information and/or mediating data. Such acontrol set represents an evolution of control information fordisseminated content. In this example the overall content control setfor a VDE content container is “evolving” as it securely (e.g.communicated in encrypted form and using authentication and digitalsignaturing techniques) passes, at least in part, to a new participant'sVDE installation where the proposed control information is securelyreceived and handled. The received control information may be integrated(through use of the receiving parties' VDE installation securesub-system) with in-place control information through a negotiationprocess involving both control information sets. For example, themodification, within the secure sub-system of a content provider's VDEinstallation, of content control information for a certain VDE contentcontainer may have occurred as a result of the incorporation of requiredcontrol information provided by a financial credit provider. Said creditprovider may have employed their VDE installation to prepare andsecurely communicate (directly or indirectly) said required controlinformation to said content provider. Incorporating said requiredcontrol information enables a content provider to allow the creditprovider's credit to be employed by a content end-user to compensate forthe end-user's use of VDE controlled content and/or appliances, so longas said end-user has a credit account with said financial creditprovider and said credit account has sufficient credit available.Similarly, control information requiring the payment of taxes and/or theprovision of revenue information resulting from electronic commerceactivities may be securely received by a content provider. This controlinformation may be received, for example, from a government agency.Content providers might be required by law to incorporate such controlinformation into the control information for commercially distributedcontent and/or services related to appliance usage. Proposed controlinformation is used to an extent allowed by senior control informationand as determined by any negotiation trade-offs that satisfy prioritiesstipulated by each set (the received set and the proposed set). VDE alsoaccommodates different control schemes specifically applying todifferent participants (e.g., individual participants and/or participantclasses (types)) in a network of VDE content handling participants.

[0202] support multiple simultaneous control models for the same contentproperty and/or property portion. This allows, for example, forconcurrent business activities which are dependent on electroniccommercial product content distribution, such as acquiring detailedmarket survey information and/or supporting advertising, both of whichcan increase revenue and result in lower content costs to users andgreater value to content providers. Such control information and/oroverall control models may be applied, as determined or allowed bycontrol information, in differing manners to different participants in apathway of content, reporting, payment, and/or related controlinformation handling. VDE supports applying different content controlinformation to the same and/or different content and/or appliance usagerelated activities, and/or to different parties in a content and/orappliance usage model, such that different parties (or classes of VDEusers, for example) are subject to differing control informationmanaging their use of electronic information content. For example,differing control models based on the category of a user as adistributor of a VDE controlled content object or an end-user of suchcontent may result in different budgets being applied. Alternatively,for example, a one distributor may have the right to distribute adifferent array of properties than another distributor from a commoncontent collection provided, for example, on optical disc). Anindividual, and/or a class or other grouping of end-users, may havedifferent costs (for example, a student, senior citizen, and/or poorcitizen user of content who may be provided with the same or differingdiscounts) than a “typical” content user.

[0203] support provider revenue information resulting from customer useof content and/or appliances, and/or provider and/or end-user payment oftaxes, through the transfer of credit and/or electronic currency fromsaid end-user and/or provider to a government agency, might occur“automatically” as a result of such received control information causingthe generation of a VDE content container whose content includescustomer content usage information reflecting secure, trusted revenuesummary information and/or detailed user transaction listings (level ofdetail might depend, for example on type or size oftransaction—information regarding a bank interest payment to a customeror a transfer of a large (e.g. over $10,000) might be, by law,automatically reported to the government). Such summary and/or detailedinformation related to taxable events and/or currency, and/or creditorcurrency transfer, may be passed along a pathway of reporting and/orpayment to the government in a VDE container. Such a container may alsobe used for other VDE related content usage reporting information.

[0204] support the flowing of content control information throughdifferent “branches” of content control information handling so as toaccommodate, under the present invention's preferred embodiment, diversecontrolled distributions of VDE controlled content. This allowsdifferent parties to employ the same initial electronic content withdiffering (perhaps competitive) control strategies. In this instance, aparty who first placed control information on content can make certaincontrol assumptions and these assumptions would evolve into morespecific and/or extensive control assumptions. These control assumptionscan evolve during the branching sequence upon content model participantssubmitting control information changes, for example, for use in“negotiating” with “in place” content control information. This canresult in new or modified content control information and/or it mightinvolve the selection of certain one or more already “in-place” contentusage control methods over in-place alternative methods, as well as thesubmission of relevant control information parameter data. This form ofevolution of different control information sets applied to differentcopies of the same electronic property content and/or appliance resultsfrom VDE control information flowing “down” through different branchesin an overall pathway of handling and control and being modifieddifferently as it diverges down these different pathway branches. Thisability of the present invention to support multiple pathway branchesfor the flow of both VDE content control information and VDE managedcontent enables an electronic commerce marketplace which supportsdiverging, competitive business partnerships, agreements, and evolvingoverall business models which can employ the same content propertiescombined, for example, in differing collections of content representingdiffering at least in part competitive products.

[0205] enable a user to securely extract, through the use of the securesubsystem at the user's VDE installation, at least a portion of thecontent included within a VDE content container to produce a new, secureobject (content container), such that the extracted information ismaintained in a continually secure manner through the extractionprocess. Formation of the new VDE container containing such extractedcontent shall result in control information consistent with, orspecified by, the source VDE content container, and/or local VDEinstallation secure subsystem as appropriate, content controlinformation. Relevant control information, such as security andadministrative information, derived, at least in part, from the parent(source) object's control information, will normally be automaticallyinserted into a new VDE content container object containing extractedVDE content. This process typically occurs under the control frameworkof a parent object and/or VDE installation control information executingat the user's VDE installation secure subsystem (with, for example, atleast a portion of this inserted control information being storedsecurely in encrypted form in one or more permissions records). In analternative embodiment, the derived content control information appliedto extracted content may be in part or whole derived from, or employ,content control information stored remotely from the VDE installationthat performed the secure extraction such as at a remote serverlocation. As with the content control information for most VDE managedcontent, features of the present invention allows the content's controlinformation to:

[0206] (a) “evolve,” for example, the extractor of content may add newcontrol methods and/or modify control parameter data, such as VDEapplication compliant methods, to the extent allowed by the content'sin-place control information. Such new control information mightspecify, for example, who may use at least a portion of the new object,and/or how said at least a portion of said extracted content may be used(e.g. when at least a portion may be used, or what portion or quantityof portions may be used);

[0207] (b) allow a user to combine additional content with at least aportion of said extracted content, such as material authored by theextractor and/or content (for example, images, video, audio, and/ortext) extracted from one or more other VDE container objects forplacement directly into the new container:

[0208] (c) allow a user to securely edit at least a portion of saidcontent while maintaining said content in a secure form within said VDEcontent container;

[0209] (d) append extracted content to a pre-existing VDE contentcontainer object and attach associated control information—in thesecases, user added information may be secured, e.g., encrypted, in partor as a whole, and may be subject to usage and/or auditing controlinformation that differs from the those applied to previously in placeobject content;

[0210] (e) preserve VDE control over one or more portions of extractedcontent after various forms of usage of said portions, for example,maintain content in securely stored form while allowing “temporary” onscreen display of content or allowing a software program to bemaintained in secure form but transiently decrypt any encryptedexecuting portion of said program (all, or only a portion, of saidprogram may be encrypted to secure the program).

[0211] Generally, the extraction features of the present invention allowusers to aggregate and/or disseminate and/or otherwise use protectedelectronic content information extracted from content container sourceswhile maintaining secure VDE capabilities thus preserving the rights ofproviders in said content information after various content usageprocesses.

[0212] support the aggregation of portions of VDE controlled content,such portions being subject to differing VDE content container controlinformation, wherein various of said portions may have been provided byindependent, different content providers from one or more differentlocations remote to the user performing the aggregation. Suchaggregation, in the preferred embodiment of the present invention, mayinvolve preserving at least a portion of the control information (e.g.,executable code such as load modules) for each of various of saidportions by, for example, embedding some or all of such portionsindividually as VDE content container objects within an overall VDEcontent container and/or embedding some or all of such portions directlyinto a VDE content container. In the latter case, content controlinformation of said content container may apply differing controlinformation sets to various of such portions based upon said portionsoriginal control information requirements before aggregation. Each ofsuch embedded VDE content containers may have its own controlinformation in the form of one or more permissions records.Alternatively, a negotiation between control information associated withvarious aggregated portions of electronic content, may produce a controlinformation set that would govern some or all of the aggregated contentportions. The VDE content control information produced by thenegotiation may be uniform (such as having the same load modules and/orcomponent assemblies, and/or it may apply differing such content controlinformation to two or more portions that constitute an aggregation ofVDE controlled content such as differing metering, budgeting, billingand/or payment models. For example, content usage payment may beautomatically made, either through a clearinghouse, or directly, todifferent content providers for different potions.

[0213] enable flexible metering of, or other collection of informationrelated to, use of electronic content and/or electronic appliances. Afeature of the present invention enables such flexibility of meteringcontrol mechanisms to accommodate a simultaneous, broad array of: (a)different parameters related to electronic information content use; (b)different increment units (bytes, documents, properties, paragraphs,images, etc.) and/or other organizations of such electronic content;and/or (c) different categories of user and/or VDE installation types,such as client organizations, departments, projects, networks, and/orindividual users, etc. This feature of the present invention can beemployed for content security, usage analysis (for example, marketsurveying), and/or compensation based upon the use and/or exposure toVDE managed content. Such metering is a flexible basis for ensuringpayment for content royalties, licensing, purchasing, and/oradvertising. A feature of the present invention provides for paymentmeans supporting flexible electronic currency and credit mechanisms,including the ability to securely maintain audit trails reflectinginformation related to use of such currency or credit. VDE supportsmultiple differing hierarchies of client organization controlinformation wherein an organization client administrator distributescontrol information specifying the usage rights of departments, users,and/or projects. Likewise, a department (division) network manager canfunction as a distributor (budgets, access rights, etc.) for departmentnetworks, projects, and/or users, etc.

[0214] provide scalable, integratable, standardized control means foruse on electronic appliances ranging from inexpensive consumer (forexample, television set-top appliances) and professional devices (andhand-held PDAs) to servers, mainframes, communication switches, etc. Thescalable transaction management/auditing technology of the presentinvention will result in more efficient and reliable interoperabilityamongst devices functioning in electronic commerce and/or data securityenvironments. As standardized physical containers have become essentialto the shipping of physical goods around the world, allowing thesephysical containers to universally “fit” unloading equipment,efficiently use truck and train space, and accommodate known arrays ofobjects (for example, boxes) in an efficient manner, so VDE electroniccontent containers may, as provided by the present invention, be able toefficiently move electronic information content (such as commerciallypublished properties, electronic currency and credit, and content auditinformation), and associated content control information, around theworld. Interoperability is fundamental to efficient electronic commerce.The design of the VDE foundation, VDE load modules, and VDE containers,are important features that enable the VDE node operating environment tobe compatible with a very broad range of electronic appliances. Theability, for example, for control methods based on load modules toexecute in very “small” and inexpensive secure sub-system environments,such as environments with very little read/write memory, while alsobeing able to execute in large memory sub-systems that may be used inmore expensive electronic appliances, supports consistency across manymachines. This consistent VDE operating environment, including itscontrol structures and container architecture, enables the use ofstandardized VDE content containers across a broad range of device typesand host operating environments. Since VDE capabilities can beseamlessly integrated as extensions, additions, and/or modifications tofundamental capabilities of electronic appliances and host operatingsystems, VDE containers, content control information, and the VDEfoundation will be able to work with many device types and these devicetypes will be able to consistently and efficiently interpret and enforceVDE control information. Through this integration users can also benefitfrom a transparent interaction with many of the capabilities of VDE. VDEintegration with software operating on a host electronic appliancesupports a variety of capabilities that would be unavailable or lesssecure without such integration. Through integration with one or moredevice applications and/or device operating environments, manycapabilities of the present invention can be presented as inherentcapabilities of a given electronic appliance, operating system, orappliance application. For example, features of the present inventioninclude: (a) VDE system software to in part extend and/or modify hostoperating systems such that they possesses VDE capabilities, such asenabling secure transaction processing and electronic informationstorage; (b) one or more application programs that in part representtools associated with VDE operation. and/or (c) code to be integratedinto application programs, wherein such code incorporates referencesinto VDE system software to integrate VDE capabilities and makes suchapplications VDE aware (for example, word processors, database retrievalapplications, spreadsheets, multimedia presentation authoring tools,film editing software, music editing software such as MIDI applicationsand the like, robotics control systems such as those associated withCAD/CAM environments and NCM software and the like, electronic mailsystems, teleconferencing software, and other data authoring, creating,handling, and/or usage applications including combinations of theabove). These one or more features (which may also be implemented infirmware or hardware) may be employed in conjunction with a VDE nodesecure hardware processing capability, such as a microcontroller(s),microprocessor(s), other CPU(s) or other digital processing logic.

[0215] employ audit reconciliation and usage pattern evaluationprocesses that assess, through certain, normally network based,transaction processing reconciliation and threshold checking activities,whether certain violations of security of a VDE arrangement haveoccurred. These processes are performed remote to VDE controlled contentend-user VDE locations by assessing, for example, purchases, and/orrequests, for electronic properties by a given VDE installation.Applications for such reconciliation activities include assessingwhether the quantity of remotely delivered VDE controlled contentcorresponds to the amount of financial credit and/or electronic currencyemployed for the use of such content. A trusted organization can acquireinformation from content providers concerning the cost for contentprovided to a given VDE installation and/or user and compare this costfor content with the credit and/or electronic currency disbursements forthat installation and/or user. Inconsistencies in the amount of contentdelivered versus the amount of disbursement can prove, and/or indicate,depending on the circumstances, whether the local VDE installation hasbeen, at least to some degree, compromised (for example, certainimportant system security functions, such as breaking encryption for atleast some portion of the secure subsystem and/or VDE controlled contentby uncovering one or more keys). Determining whether irregular patterns(e.g. unusually high demand) of content usage, or requests for deliveryof certain kinds of VDE controlled information during a certain timeperiod by one or more VDE installations and/or users (including, forexample, groups of related users whose aggregate pattern of usage issuspicious) may also be useful in determining whether security at suchone or more installations, and/or by such one or more users, has beencompromised, particularly when used in combination with an assessment ofelectronic credit and/or currency provided to one or more VDE usersand/or installations, by some or all of their credit and/or currencysuppliers, compared with the disbursements made by such users and/orinstallations.

[0216] support security techniques that materially increase the timerequired to “break” a system's integrity. This includes using acollection of techniques that minimizes the damage resulting fromcomprising some aspect of the security features of the presentinventions.

[0217] provide a family of authoring, administrative, reporting,payment, and billing tool user applications that comprise components ofthe present invention's trusted/secure, universe wide, distributedtransaction control and administration system. These components supportVDE related: object creation (including placing control information oncontent), secure object distribution and management (includingdistribution control information, financial related, and other usageanalysis), client internal VDE activities administration and control,security management, user interfaces, payment disbursement, andclearinghouse related functions. These components are designed tosupport highly secure, uniform, consistent, and standardized: electroniccommerce and/or data security pathway(s) of handling, reporting, and/orpayment; content control and administration; and human factors (e.g.user interfaces).

[0218] support the operation of a plurality of clearinghouses,including, for example, both financial and user clearinghouseactivities, such as those performed by a client administrator in a largeorganization to assist in the organization's use of a VDE arrangement,including usage information analysis, and control of VDE activities byindividuals and groups of employees such as specifying budgets and thecharacter of usage rights available under VDE for certain groups ofand/or individual, client personnel, subject to control informationseries to control information submitted by the client administrator. Ata clearinghouse, one or more VDE installations may operate together witha trusted distributed database environment (which may include concurrentdatabase processing means). A financial clearinghouse normally receivesat its location securely delivered content usage information, and userrequests (such as requests for further credit, electronic currency,and/or higher credit limit). Reporting of usage information and userrequests can be used for supporting electronic currency, billing,payment and credit related activities, and/or for user profile analysisand/or broader market survey analysis and marketing (consolidated) listgeneration or other information derived, at least in part, from saidusage information, this information can be provided to content providersor other parties, through secure, authenticated encrypted communicationto the VDE installation secure subsystems. Clearinghouse processingmeans would normally be connected to specialized I/O means, which mayinclude high speed telecommunication switching means that may be usedfor secure communications between a clearinghouse and other VDE pathwayparticipants.

[0219] securely support electronic currency and credit usage control,storage, and communication at, and between, VDE installations. VDEfurther supports automated passing of electronic currency and/or creditinformation, including payment tokens (such as in the form of electroniccurrency or credit) or other payment information, through a pathway ofpayment, which said pathway may or may not be the same as a pathway forcontent usage information reporting. Such payment may be placed into aVDE container created automatically by a VDE installation in response tocontrol information stipulating the “withdrawal” of credit or electroniccurrency from an electronic credit or currency account based upon anamount owed resulting from usage of VDE controlled electronic contentand/or appliances. Payment credit or currency may then be automaticallycommunicated in protected (at least in part encrypted) form throughtelecommunication of a VDE container to an appropriate party such as aclearinghouse, provider of original property content or appliance, or anagent for such provider (other than a clearinghouse). Paymentinformation may be packaged in said VDE content container with, orwithout, related content usage information, such as meteringinformation. An aspect of the present invention further enables certaininformation regarding currency use to be specified as unavailable tocertain, some, or all VDE parties (“conditionally” to fully anonymouscurrency) and/or further can regulate certain content information, suchas currency and/or credit use related information (and/or otherelectronic information usage data) to be available only under certainstrict circumstances, such as a court order (which may itself requireauthorization through the use of a court controlled VDE installationthat may be required to securely access “conditionally” anonymousinformation). Currency and credit information, under the preferredembodiment of the present invention, is treated as administrativecontent;

[0220] support fingerprinting (also known as watermarking) for embeddingin content such that when content protected under the present inventionis released in clear form from a VDE object (displayed, printed,communicated, extracted, and/or saved), information representing theidentification of the user and/or VDE installation responsible fortransforming the content into clear form is embedded into the releasedcontent. Fingerprinting is useful in providing an ability to identifywho extracted information in clear form a VDE container, or who made acopy of a VDE object or a portion of its contents. Since the identity ofthe user and/or other identifying information may be embedded in anobscure or generally concealed manner, in VDE container content and/orcontrol information, potential copyright violators may be deterred fromunauthorized extraction or copying. Fingerprinting normally is embeddedinto unencrypted electronic content or control information, though itcan be embedded into encrypted content and later placed in unencryptedcontent in a secure VDE installation sub-system as the encrypted contentcarrying the fingerprinting information is decrypted. Electronicinformation, such as the content of a VDE container, may befingerprinted as it leaves a network (such as Internet) location boundfor a receiving party. Such repository information may be maintained inunencrypted form prior to communication and be encrypted as it leavesthe repository. Fingerprinting would preferably take place as thecontent leaves the repository, but before the encryption step. Encryptedrepository content can be decrypted, for example in a secure VDEsub-system, fingerprint information can be inserted, and then thecontent can be re-encrypted for transmission. Embedding identificationinformation of the intended recipient user and/or VDE installation intocontent as it leaves, for example, an Internet repository, would provideimportant information that would identify or assist in identifying anyparty that managed to compromise the security of a VDE installation orthe delivered content. If a party produces an authorized clear form copyof VDE controlled content, including making unauthorized copies of anauthorized clear form copy, fingerprint information would point back tothat individual and/or his or her VDE installation. Such hiddeninformation will act as a strong disincentive that should dissuade asubstantial portion of potential content “pirates” from stealing otherparties electronic information. Fingerprint information identifying areceiving party and/or VDE installation can be embedded into a VDEobject before, or during, decryption, replication, or communication ofVDE content objects to receivers. Fingerprinting electronic contentbefore it is encrypted for transfer to a customer or other user providesinformation that can be very useful for identifying who received certaincontent which may have then been distributed or made available inunencrypted form. This information would be useful in tracking who mayhave “broken” the security of a VDE installation and was illegallymaking certain electronic content available to others. Fingerprintingmay provide additional, available information such as time and/or dateof the release (for example extraction) of said content information.Locations for inserting fingerprints may be specified by VDEinstallation and/or content container control information. Thisinformation may specify that certain areas and/or precise locationswithin properties should be used for fingerprinting, such as one or morecertain fields of information or information types. Fingerprintinginformation may be incorporated into a property by modifying in anormally undetectable way color frequency and/or the brightness ofcertain image pixels, by slightly modifying certain audio signals as tofrequency, by modifying font character formation, etc. Fingerprintinformation, itself, should be encrypted so as to make it particularlydifficult for tampered fingerprints to be interpreted as valid.Variations in fingerprint locations for different copies of the sameproperty; “false” fingerprint information; and multiple copies offingerprint information within a specific property or other contentwhich copies employ different fingerprinting techniques such asinformation distribution patterns, frequency and/or brightnessmanipulation, and encryption related techniques, are features of thepresent invention for increasing the difficulty of an unauthorizedindividual identifying fingerprint locations and erasing and/ormodifying fingerprint information.

[0221] provide smart object agents that can carry requests, data, and/ormethods, including budgets, authorizations, credit or currency, andcontent. For example, smart objects may travel to and/or from remoteinformation resource locations and fulfill requests for electronicinformation content. Smart objects can, for example, be transmitted to aremote location to perform a specified database search on behalf of auser or otherwise “intelligently” search remote one or more repositoriesof information for user desired information. After identifying desiredinformation at one or more remote locations, by for example, performingone or more database searches, a smart object may return viacommunication to the user in the form of a secure “return object”containing retrieved information. A user may be charged for the remoteretrieving of information, the returning of information to the user'sVDE installation, and/or the use of such information. In the lattercase, a user may be charged only for the information in the returnobject that the user actually uses. Smart objects may have the means torequest use of one or more services and/or resources. Services includelocating other services and/or resources such as information resources,language or format translation, processing, credit (or additionalcredit) authorization, etc. Resources include reference databases,networks, high powered or specialized computing resources (the smartobject may carry information to another computer to be efficientlyprocessed and then return the information to the sending VDEinstallation), remote object repositories, etc. Smart objects can makeefficient use of remote resources (e.g. centralized databases, supercomputers, etc.) while providing a secure means for charging users basedon information and/or resources actually used.

[0222] support both “translations” of VDE electronic agreements elementsinto modern language printed agreement elements (such as Englishlanguage agreements) and translations of electronic rightsprotection/transaction management modern language agreement elements toelectronic VIE agreement elements. This feature requires maintaining alibrary of textual language that corresponds to VDE load modules and/ormethods and/or component assemblies. As VDE methods are proposed and/oremployed for VDE agreements, a listing of textual terms and conditionscan be produced by a VDE user application which, in a preferredembodiment, provides phrases, sentences and/or paragraphs that have beenstored and correspond to said methods and/or assemblies. This featurepreferably employs artificial intelligence capabilities to analyze andautomatically determine, and/or assist one or more users to determine,the proper order and relationship between the library elementscorresponding to the chosen methods and/or assemblies so as to composesome or all portions of a legal or descriptive document. One or moreusers, and/or preferably an attorney (if the document a legal, bindingagreement), would review the generated document material upon completionand employ such additional textual information and/or editing asnecessary to describe non electronic transaction elements of theagreement and make any other improvements that may be necessary. Thesefeatures further support employing modern language tools that allow oneor more users to make selections from choices and provide answers toquestions and to produce a VDE electronic agreement from such a process.This process can be interactive and the VDE agreement formulationprocess may employ artificial intelligence expert system technology thatlearns from responses and, where appropriate and based at least in parton said responses, provides further choices and/or questions which“evolves” the desired VDE electronic agreement.

[0223] support the use of multiple VDE secure subsystems in a single VDEinstallation. Various security and/or performance advantages may berealized by employing a distributed VDE design within a single VDEinstallation. For example, designing a hardware based VDE securesubsystem into an electronic appliance VDE display device, and designingsaid subsystem's integration with said display device so that it is asclose as possible to the point of display, will increase the securityfor video materials by making it materially more difficult to “steal”decrypted video information as it moves from outside to inside the videosystem. Ideally, for example, a VDE secure hardware module would be inthe same physical package as the actual display monitor, such as withinthe packaging of a video monitor or other display device, and suchdevice would be designed, to the extent commercially practical, to be astamper resistant as reasonable. As another example, embedding a VDEhardware module into an I/O peripheral may have certain advantages fromthe standpoint of overall system throughput. If multiple VDE instancesare employed within the same VDE installation, these instances willideally share resources to the extent practical, such as VDE instancesstoring certain control information and content and/or appliance usageinformation on the same mass storage device and in the same VDEmanagement database.

[0224] requiring reporting and payment compliance by employingexhaustion of budgets and time ageing of keys. For example, a VDEcommercial arrangement and associated content control information mayinvolve a content providers content and the use of clearinghouse creditfor payment for end-user usage of said content. Control informationregarding said arrangement may be delivered to a user's (of saidcontent) VDE installation and/or said financial clearinghouse's VDEinstallation. Said control information might require said clearinghouseto prepare and telecommunicate to said content provider both contentusage based information in a certain form, and content usage payment inthe form of electronic credit (such credit might be “owned” by theprovider after receipt and used in lieu of the availability or adequacyof electronic currency) and/or electronic currency. This delivery ofinformation and payment may employ trusted VDE installation securesubsystems to securely, and in some embodiments, automatically, providein the manner specified by said control information, said usageinformation and payment content. Features of the present invention helpensure that a requirement that a clearinghouse report such usageinformation and payment content will be observed. For example, if oneparticipant to a VDE electronic agreement fails to observe suchinformation reporting and/or paying obligation, another participant canstop the delinquent party from successfully participating in VDEactivities related to such agreement. For example, if required usageinformation and payment was not reported as specified by content controlinformation, the “injured” party can fail to provide, through failing tosecurely communicate from his VDE installation secure subsystem, one ormore pieces of secure information necessary for the continuance of oneor more critical processes. For example, failure to report informationand/or payment from a clearinghouse to a content provider (as well asany security failures or other disturbing irregularities) can result inthe content provider not providing key and/or budget refresh informationto the clearinghouse, which information can be necessary to authorizeuse of the clearinghouse's credit for usage of the provider's contentand which the clearinghouse would communicate to end-user's during acontent usage reporting communication between the clearinghouse andend-user. As another example, a distributor that failed to make paymentsand/or report usage information to a content provider might find thattheir budget for creating permissions records to distribute the contentprovider's content to users, and/or a security budget limiting one ormore other aspect of their use of the provider's content, are not beingrefreshed by the content provider, once exhausted or timed-out (forexample, at a predetermined date). In these and other cases, theoffended party might decide not to refresh time ageing keys that had“aged out.” Such a use of time aged keys has a similar impact as failingto refresh budgets or time-aged authorizations.

[0225] support smart card implementations of the present invention inthe form of portable electronic appliances, including cards that can beemployed as secure credit, banking, and/or money cards. A feature of thepresent invention is the use of portable VDEs as transaction cards atretail and other establishments, wherein such cards can “dock” with anestablishment terminal that has VDE secure sub-system and/or an onlineconnection to a VDE secure and/or otherwise secure and compatiblesubsystem, such as a “trusted” financial clearinghouse (e.g., VISA,Mastercard). The VDE card and the terminal (and/or online connection)can securely exchange information related to a transaction, with creditand/or electronic currency being transferred to a merchant and/orclearinghouse and transaction information flowing back to the card. Sucha card can be used for transaction activities of all sorts. A dockingstation, such as a PCMCLA connector on an electronic appliance, such asa personal computer, can receive a consumer's VDE card at home. Such astation/card combination can be used for on-line transactions in thesame manner as a VDE installation that is permanently installed in suchan electronic appliance. The card can be used as an “electronic wallet”and contain electronic currency as well as credit provided by aclearinghouse. The card can act as a convergence point for financialactivities of a consumer regarding many, if not all, merchant, banking,and on-line financial transactions, including supporting home bankingactivities. A consumer can receive his paycheck and/or investmentearnings and/or “authentic” VDE content container secured detailedinformation on such receipts, through on-line connections. A user cansend digital currency to another party with a VDE arrangement, includinggiving away such currency. A VDE card can retain details of transactionsin a highly secure and database organized fashion so that financiallyrelated information is both consolidated and very easily retrievedand/or analyzed. Because of the VDE security, including use of effectiveencryption, authentication, digital signaturing, and secure databasestructures, the records contained within a VDE card arrangement may beaccepted as valid transaction records for government and/or corporaterecordkeeping requirements. In some embodiments of the present inventiona VDE card may employ docking station and/or electronic appliancestorage means and/or share other VDE arrangement means local to saidappliance and/or available across a network, to augment the informationstorage capacity of the VDE card, by for example, storing dated, and/orarchived, backup information. Taxes relating to some or all of anindividual's financial activities may be automatically computed based on“authentic” information securely stored and available to said VDE card.Said information may be stored in said card, in said docking station, inan associated electronic appliance, and/or other device operativelyattached thereto, and/or remotely, such as at a remote server site. Acard's data, e.g. transaction history, can be backed up to anindividual's personal computer or other electronic appliance and such anappliance may have an integrated VDE installation of its own. A currenttransaction, recent transactions (for redundancy), or all or otherselected card data may be backed up to a remote backup repository, sucha VDE compatible repository at a financial clearinghouse, during each orperiodic docking for a financial transaction and/or informationcommunication such as a user/merchant transaction. Backing up at leastthe current transaction during a connection with another party's VDEinstallation (for example a VDE installation that is also on a financialor general purpose electronic network), by posting transactioninformation to a remote clearinghouse and/or bank, can ensure thatsufficient backup is conducted to enable complete reconstruction of VDEcard internal information in the event of a card failure or loss.

[0226] support certification processes that ensure authorizedinteroperability between various VDE installations so as to prevent VDEarrangements and/or installations that unacceptably deviate inspecification protocols from other VDE arrangements and/or installationsfrom interoperating in a manner that may introduce security (integrityand/or confidentiality of VDE secured information), process control,and/or software compatibility problems. Certification validates theidentity of VDE installations and/or their components, as well as VDEusers. Certification data can also serve as information that contributesto determining the decommissioning or other change related to VDE sites.

[0227] support the separation of fundamental transaction controlprocesses through the use of event (triggered) based method controlmechanisms. These event methods trigger one or more other VDE methods(which are available to a secure VDE sub-system) and are used to carryout VDE managed transaction related processing. These triggered methodsinclude independently (separably) and securely processable componentbilling management methods, budgeting management methods, meteringmanagement methods, and related auditing management processes. As aresult of this feature of the present invention, independent triggeringof metering, auditing, billing, and budgeting methods, the presentinvention is able to efficiently, concurrently support multiplefinancial currencies (e.g. dollars, marks, yen) and content relatedbudgets, and/or billing increments as well as very flexible contentdistribution models.

[0228] support, complete, modular separation of the control structuresrelated to (1) content event triggering, (2) auditing, (3) budgeting(including specifying no right of use or limited right of use), (4)billing, and (5) user identity (VDE installation, client name,department, network, and/or user, etc.). The independence of these VDEcontrol structures provides a flexible system which allows pluralrelationships between two or more of these structures, for example, theability to associate a financial budget with different event triggerstructures (that are put in place to enable controlling content based onits logical portions). Without such separation between these basic VDEcapabilities, it would be more difficult to efficiently maintainseparate metering, budgeting, identification, and/or billing activitieswhich involve the same, differing (including overlapping), or entirelydifferent, portions of content for metering, billing, budgeting, anduser identification, for example, paying fees associated with usage ofcontent, performing home banking, managing advertising services, etc.VDE modular separation of these basic capabilities supports theprogramming of plural, “arbitrary” relationships between one ordiffering content portions (and/or portion units) and budgeting,auditing, and/or billing control information. For example, under VDE, abudget limit of $200 dollars or 300 German Marks a month may be enforcedfor decryption of a certain database and 2 U.S. Dollars or 3 GermanMarks may be charged for each record of said database decrypted(depending on user selected currency). Such usage can be metered whilean additional audit for user profile purposes can be prepared recordingthe identity of each filed displayed. Additionally, further metering canbe conducted regarding the number of said database bytes that have beendecrypted, and a related security budget may prevent the decrypting ofmore than 5% of the total bytes of said database per year. The user mayalso, under VDE (if allowed by senior control information), collectaudit information reflecting usage of database fields by differentindividuals and client organization departments and ensure thatdiffering rights of access and differing budgets limiting database usagecan be applied to these client individuals and groups. Enabling contentproviders and users to practically employ such diverse sets of useridentification, metering, budgeting, and billing control informationresults, in part, from the use of such independent control capabilities.As a result, VDE can support great configurability in creation of pluralcontrol models applied to the same electronic property and the sameand/or plural control models applied to differing or entirely differentcontent models (for example, home banking versus electronic shopping).

[0229] Methods, Other Control Information, and VDE Objects

[0230] VDE control information (e.g., methods) that collectively controluse of VDE managed properties (database, document, individual commercialproduct), are either shipped with the content itself (for example, in acontent container) and/or one or more portions of such controlinformation is shipped to distributors and/or other users in separablydeliverable “administrative objects.” A subset of the methods for aproperty may in part be delivered with each property while one or moreother subsets of methods can be delivered separately to a user orotherwise made available for use (such as being available remotely bytelecommunication means). Required methods (methods listed as requiredfor property and/or appliance use) must be available as specified if VDEcontrolled content (such as intellectual property distributed within aVDE content container) is to be used. Methods that control content mayapply to a plurality of VDE container objects, such as a class or othergrouping of such objects. Methods may also be required by certain usersor classes of users and/or VDE installations and/or classes ofinstallations for such parties to use one or more specific, or classesof, objects.

[0231] A feature of VDE provided by the present invention is thatcertain one or more methods can be specified as required in order for aVDE installation and/or user to be able to use certain and/or allcontent. For example, a distributor of a certain type of content mightbe allowed by “senior” participants (by content creators, for example)to require a method which prohibits end-users from electronically savingdecrypted content, a provider of credit for VDE transactions mightrequire an audit method that records the time of an electronic purchase,and/or a user might require a method that summarizes usage informationfor reporting to a clearinghouse (e.g. billing information) in a waythat does not convey confidential, personal information regardingdetailed usage behavior.

[0232] A further feature of VDE provided by the present invention isthat creators, distributors, and users of content can select from amonga set of predefined methods (if available) to control container contentusage and distribution functions and/or they may have the right toprovide new customized methods to control at least certain usagefunctions (such “new” methods may be required to be certified fortrustedness and interoperability to the VDE installation and/or for of agroup of VDE applications). As a result, VDE provides a very high degreeof configurability with respect to how the distribution and other usageof each property or object (or one or more portions of objects orproperties as desired and/or applicable) will be controlled. Each VDEparticipant in a VDE pathway of content control information may setmethods for some or all of the content in a VDE container, so long assuch control information does not conflict with senior controlinformation already in place with respect to:

[0233] (1) certain or all VDE managed content,

[0234] (2) certain one or more VDE users and/or groupings of users,

[0235] (3) certain one or more VDE nodes and/or groupings of nodes,and/or

[0236] (4) certain one or more VDE applications and/or arrangements.

[0237] For example, a content creator's VDE control information forcertain content can take precedence over other submitted VDE participantcontrol information and, for example, if allowed by senior controlinformation, a content distributor's control information may itself takeprecedence over a client administrator's control information, which maytake precedence over an end-user's control information. A path ofdistribution participant's ability to set such electronic contentcontrol information can be limited to certain control information (forexample, method mediating data such as pricing and/or sales dates) or itmay be limited only to the extent that one or more of the participant'sproposed control information conflicts with control information set bysenior control information submitted previously by participants in achain of handling of the property, or managed in said participant's VDEsecure subsystem.

[0238] VDE control information may, in part or in full, (a) representcontrol information directly put in place by VDE content controlinformation pathway participants, and/or (b) comprise controlinformation put in place by such a participant on behalf of a party whodoes not directly handle electronic content (or electronic appliance)permissions records information (for example control informationinserted by a participant on behalf of a financial clearinghouse orgovernment agency). Such control information methods (and/or loadmodules and/or mediating data and/or component assemblies) may also beput in place by either an electronic automated, or a semi-automated andhuman assisted, control information (control set) negotiating processthat assesses whether the use of one or more pieces of submitted controlinformation will be integrated into and/or replace existing controlinformation (and/or chooses between alternative control informationbased upon interaction with in-place control information) and how suchcontrol information may be used.

[0239] Control information may be provided by a party who does notdirectly participate in the handling of electronic content (and/orappliance) and/or control information for such content (and/orappliance). Such control information may be provided in secure formusing VDE installation secure sub-system managed communications(including, for example, authenticating the deliverer of at least inpart encrypted control information) between such not directlyparticipating one or more parties' VDE installation secure subsystems,and a pathway of VDE content control information participant's VDEinstallation secure subsystem. This control information may relate to,for example, the right to access credit supplied by a financial servicesprovider, the enforcement of regulations or laws enacted by a governmentagency, or the requirements of a customer of VDE managed content usageinformation (reflecting usage of content by one or more parties otherthan such customer) relating to the creation, handling and/or manner ofreporting of usage information received by such customer. Such controlinformation may, for example, enforce societal requirements such as lawsrelated to electronic commerce.

[0240] VDE content control information may apply differently todifferent pathway of content and/or control information handlingparticipants. Furthermore, permissions records rights may be added,altered, and/or removed by a VDE participant if they are allowed to takesuch action. Rights of VDE participants may be defined in relation tospecific parties and/or categories of parties and/or other groups ofparties in a chain of handling of content and/or content controlinformation (e.g., permissions records). Modifications to controlinformation that may be made by a given, eligible party or parties, maybe limited in the number of modifications, and/or degree ofmodification, they may make.

[0241] At least one secure subsystem in electronic appliances ofcreators, distributors, auditors, clearinghouses, client administrators,and end-users (understanding that two or more of the aboveclassifications may describe a single user) provides a “sufficiently”secure (for the intended applications) environment for:

[0242] 1. Decrypting properties and control information;

[0243] 2. Storing control and metering related information;

[0244] 3. Managing communications;

[0245] 4. Processing core control programs, along with associated data,that constitute control information for electronic content and/orappliance rights protection, including the enforcing of preferences andrequirements of VDE participants.

[0246] Normally, most usage, audit, reporting, payment, and distributioncontrol methods are themselves at least in part encrypted and areexecuted by the secure subsystem of a VDE installation. Thus, forexample, billing and metering records can be securely generated andupdated, and encryption and decryption keys are securely utilized,within a secure subsystem. Since VDE also employs secure (e.g. encryptedand authenticated) communications when passing information between theparticipant location (nodes) secure subsystems of a VDE arrangement,important components of a VDE electronic agreement can be reliablyenforced with sufficient security (sufficiently trusted) for theintended commercial purposes. A VDE electronic agreement for a valuechain can be composed, at least in part, of one or more subagreementsbetween one or more subsets of the value chain participants. Thesesubagreements are comprised of one or more electronic contract“compliance” elements (methods including associated parameter data) thatensure the protection of the rights of VDE participants.

[0247] The degree of trustedness of a VDE arrangement will be primarilybased on whether hardware SPUs are employed at participant locationsecure subsystems and the effectiveness of the SPU hardware securityarchitecture, software security techniques when an SPU is emulated insoftware, and the encryption algorithm(s) and keys that are employed forsecuring content, control information, communications, and access to VDEnode (VDE installation) secure subsystems. Physical facility and useridentity authentication security procedures may be used instead ofhardware SPUs at certain nodes, such as at an established financialclearinghouse, where such procedures may provide sufficient security fortrusted interoperability with a VDE arrangement employing hardware SPUsat user nodes.

[0248] The updating of property management files at each location of aVDE arrangement, to accommodate new or modified control information, isperformed in the VDE secure subsystem and under the control of securemanagement file updating programs executed by the protected subsystem.Since all secure communications are at least in part encrypted and theprocessing inside the secure subsystem is concealed from outsideobservation and interference, the present invention ensures that contentcontrol information can be enforced. As a result, the creator and/ordistributor and/or client administrator and/or other contributor ofsecure control information for each property (for example, an end-userrestricting the kind of audit information he or she will allow to bereported and/or a financial clearinghouse establishing certain criteriafor use of its credit for payment for use of distributed content) can beconfident that their contributed and accepted control information willbe enforced (within the security limitations of a given VDE securityimplementation design). This control information can determine, forexample:

[0249] (1) How and/or to whom electronic content can be provided, forexample, how an electronic property can be distributed;

[0250] (2) How one or more objects and/or properties, or portions of anobject or property, can be directly used, such as decrypted, displayed,printed, etc:

[0251] (3) How payment for usage of such content and/or content portionsmay or must be handled; and

[0252] (4) How audit information about usage information related to atleast a portion of a property should be collected, reported, and/orused.

[0253] Seniority of contributed control information, includingresolution of conflicts between content control information submitted bymultiple parties, is normally established by:

[0254] (1) the sequence in which control information is put in place byvarious parties (in place control information normally takes precedenceover subsequently submitted control information),

[0255] (2) the specifics of VDE content and/or appliance controlinformation. For example, in-place control information can stipulatewhich subsequent one or more piece of control from one or more partiesor class of parties will take precedence over control informationsubmitted by one or more yet different parties and/or classes ofparties, and/or

[0256] (3) negotiation between control information sets from pluralparties, which negotiation establishes what control information shallconstitute the resulting control information set for a given piece ofVDE managed content and/or VDE installation.

[0257] Electronic Agreements and Rights Protection

[0258] An important feature of VDE is that it can be used to assure theadministration of, and adequacy of security and rights protection for,electronic agreements implemented through the use of the presentinvention. Such agreements may involve one or more of:

[0259] (1) creators, publishers, and other distributors, of electronicinformation,

[0260] (2) financial service (e.g. credit) providers,

[0261] (3) users of (other than financial service providers) informationarising from content usage such as content specific demographicinformation and user specific descriptive information. Such users mayinclude market analysts, marketing list compilers for direct anddirected marketing, and government agencies,

[0262] (4) end users of content,

[0263] (5) infrastructure service and device providers such astelecommunication companies and hardware manufacturers (semiconductorand electronic appliance and/or other computer system manufacturers) whoreceive compensation based upon the use of their services and/ordevices, and

[0264] (6) certain parties described by electronic information.

[0265] VDE supports commercially secure “extended” value chainelectronic agreements. VDE can be configured to support the variousunderlying agreements between parties that comprise this extendedagreement. These agreements can define important electronic commerceconsiderations including:

[0266] (1) security,

[0267] (2) content use control, including electronic distribution,

[0268] (3) privacy (regarding, for example, information concerningparties described by medical, credit, tax, personal, and/or of otherforms of confidential information),

[0269] (4) management of financial processes, and

[0270] (5) pathways of handling for electronic content, content and/orappliance control information, electronic content and/or appliance usageinformation and payment and/or credit.

[0271] VDE agreements may define the electronic commerce relationship oftwo or more parties of a value chain, but such agreements may, at times,not directly obligate or otherwise directly involve other VDE valuechain participants. For example, an electronic agreement between acontent creator and a distributor may establish both the price to thedistributor for a creator's content (such as for a property distributedin a VDE container object) and the number of copies of this object thatthis distributor may distribute to end-users over a given period oftime. In a second agreement, a value chain end-user may be involved in athree party agreement in which the end-user agrees to certainrequirements for using the distributed product such as acceptingdistributor charges for content use and agreeing to observe thecopyright rights of the creator. A third agreement might exist betweenthe distributor and a financial clearinghouse that allows thedistributor to employ the clearinghouse's credit for payment for theproduct if the end-user has a separate (fourth) agreement directly withthe clearinghouse extending credit to the end-user. A fifth, evolvingagreement may develop between all value chain participants as contentcontrol information passes along its chain of handling. This evolvingagreement can establish the rights of all parties to content usageinformation, including, for example, the nature of information to bereceived by each party and the pathway of handling of content usageinformation and related procedures. A sixth agreement in this example,may involve all parties to the agreement and establishes certain generalassumptions, such as security techniques and degree of trustedness (forexample, commercial integrity of the system may require each VDEinstallation secure subsystem to electronically warrant that their VDEnode meets certain interoperability requirements). In the above example,these six agreements could comprise agreements of an extended agreementfor this commercial value chain instance.

[0272] VDE agreements support evolving (“living”) electronic agreementarrangements that can be modified by current and/or new participantsthrough very simple to sophisticated “negotiations” between newlyproposed content control information interacting with controlinformation already in place and/or by negotiation between concurrentlyproposed content control information submitted by a plurality ofparties. A given model may be asynchronously and progressively modifiedover time in accordance with existing senior rules and such modificationmay be applied to all, to classes of, and/or to specific content, and/orto classes and/or specific users and/or user nodes. A given piece ofcontent may be subject to different control information at differenttimes or places of handling, depending on the evolution of its contentcontrol information (and/or on differing, applicable VDE installationcontent control information). The evolution of control information canoccur during the passing along of one or more VDE control informationcontaining objects, that is control information may be modified at oneor more points along a chain of control information handling, so long assuch modification is allowed. As a result, VDE managed content may havedifferent control information applied at both different “locations” in achain of content handling and at similar locations in differing chainsof the handling of such content. Such different application of controlinformation may also result from content control information specifyingthat a certain party or group of parties shall be subject to contentcontrol information that differs from another party or group of parties.For example, content control information for a given piece of contentmay be stipulated as senior information and therefore not changeable,might be put in place by a content creator and might stipulate thatnational distributors of a given piece of their content may be permittedto make 100,000 copies per calendar quarter, so long as such copies areprovided to boni fide end-users, but may pass only a single copy of suchcontent to a local retailers and the control information limits such aretailer to making no more than 1,000 copies per month for retail salesto end-users. In addition, for example, an end-user of such contentmight be limited by the same content control information to making threecopies of such content, one for each of three different computers he orshe uses (one desktop computer at work, one for a desktop computer athome, and one for a portable computer).

[0273] Electronic agreements supported by the preferred embodiment ofthe present invention can vary from very simple to very elaborate. Theycan support widely diverse information management models that providefor electronic information security, usage administration, andcommunication and may support:

[0274] (a) secure electronic distribution of information, for examplecommercial literary properties,

[0275] (b) secure electronic information usage monitoring and reporting,

[0276] (c) secure financial transaction capabilities related to bothelectronic information and/or appliance usage and other electroniccredit and/or currency usage and administration capabilities,

[0277] (d) privacy protection for usage information a user does not wishto release, and

[0278] (e) “living” electronic information content dissemination modelsthat flexibly accommodate:

[0279] (1) a breadth of participants,

[0280] (2) one or more pathways (chains) for: the handling of content,content and/or appliance control information, reporting of contentand/or appliance usage related information, and/or payment,

[0281] (3) supporting an evolution of terms and conditions incorporatedinto content control information, including use of electronicnegotiation capabilities,

[0282] (4) support the combination of multiple pieces of content to formnew content aggregations, and

[0283] (5) multiple concurrent models.

[0284] Secure Processing Units

[0285] An important part of VDE provided by the present invention is thecore secure transaction control arrangement, herein called an SPU (orSPUs), that typically must be present in each user's computer, otherelectronic appliance, or network. SPUs provide a trusted environment forgenerating decryption keys, encrypting and decrypting information,managing the secure communication of keys and other information betweenelectronic appliances (i.e. between VDE installations and/or betweenplural VDE instances within a single VDE installation), securelyaccumulating and managing audit trail, reporting, and budget informationin secure and/or non-secure non-volatile memory, maintaining a securedatabase of control information management instructions, and providing asecure environment for performing certain other control andadministrative functions.

[0286] A hardware SPU (rather than a software emulation) within a VDEnode is necessary if a highly trusted environment for performing certainVDE activities is required. Such a trusted environment may be createdthrough the use of certain control software, one or more tamperresistant hardware modules such as a semiconductor or semiconductorchipset (including, for example, a tamper resistant hardware electronicappliance peripheral device), for use within, and/or operativelyconnected to, an electronic appliance. With the present invention, thetrustedness of a hardware SPU can be enhanced by enclosing some or allof its hardware elements within tamper resistant packaging and/or byemploying other tamper resisting techniques (e.g. microfusing and/orthin wire detection techniques). A trusted environment of the presentinvention implemented, in part, through the use of tamper resistantsemiconductor design, contains control logic, such as a microprocessor,that securely executes VDE processes.

[0287] A VDE node's hardware SPU is a core component of a VDE securesubsystem and may employ some or all of an electronic appliance'sprimary control logic, such as a microcontroller, microcomputer or otherCPU arrangement. This primary control logic may be otherwise employedfor non VDE purposes such as the control of some or all of an electronicappliance's non-VDE functions. When operating in a hardware SPU mode,said primary control logic must be sufficiently secure so as to protectand conceal important VDE processes. For example, a hardware SPU mayemploy a host electronic appliance microcomputer operating in protectedmode while performing VDE related activities, thus allowing portions ofVDE processes to execute with a certain degree of security. Thisalternate embodiment is in contrast to the preferred embodiment whereina trusted environment is created using a combination of one or moretamper resistant semiconductors that are not part of said primarycontrol logic. In either embodiment, certain control information(software and parameter data) must be securely maintained within theSPU, and fisher control information can be stored externally andsecurely (e.g. in encrypted and tagged form) and loaded into saidhardware SPU when needed. In many cases, and in particular withmicrocomputers, the preferred embodiment approach of employing specialpurpose secure hardware for executing said VDE processes, rather thanusing said primary control logic, may be more secure and efficient. Thelevel of security and tamper resistance required for trusted SPUhardware processes depends on the commercial requirements of particularmarkets or market niches, and may vary widely.

BRIEF DESCRIPTION OF THE DRAWINGS

[0288] These and other features and advantages provided by the presentinvention(s) may be better and more completely understood by referringto the following detailed description of presently preferred exampleembodiments in connection with the drawings, of which:

[0289]FIG. 1 illustrates an example of a “Virtual DistributionEnvironment” provided in accordance with a preferred example/embodimentof this invention;

[0290]FIG. 1A is a more detailed illustration of an example of the“Information Utility” shown in FIG. 1;

[0291]FIG. 2 illustrates an example of a chain of handling and control;

[0292]FIG. 2A illustrates one example of how rules and controlinformation may persist from one participant to another in the FIG. 2chain of handling and control;

[0293]FIG. 3 shows one example of different control information that maybe provided;

[0294]FIG. 4 illustrates examples of some different types of rulesand/or control information;

[0295]FIGS. 5A and 5B show an example of an “object”;

[0296]FIG. 6 shows an example of a Secure Processing Unit (“SPU”);

[0297]FIG. 7 shows an example of an electronic appliance;

[0298]FIG. 8 is a more detailed block diagram of an example of theelectronic appliance shown in FIG. 7;

[0299]FIG. 9 is a detailed view of an example of the Secure ProcessingUnit (SPU) shown in FIGS. 6 and 8;

[0300]FIG. 9A shows an example combined secure processing unit andcontrol processing unit;

[0301]FIG. 9B shows an example secure processing unit integrated with astandard CPU;

[0302]FIG. 10 shows an example of a “Rights Operating System” (“ROS”)architecture provided by the Virtual Distribution Environment;

[0303] FIGS. 11A-11C show examples of functional relationship(s) betweenapplications and the Rights Operating System;

[0304] FIGS. 11D-11J show examples of “components” and “componentassemblies”;

[0305]FIG. 12 is a more detailed diagram of an example of the RightsOperating System shown in FIG. 10;

[0306]FIG. 12A shows an example of how “objects” can be created;

[0307]FIG. 13 is a detailed block diagram of an example the softwarearchitecture for a “protected processing environment” shown in FIG. 12;

[0308] FIGS. 14A-14C are examples of SPU memory maps provided by theprotected processing environment shown in FIG. 13;

[0309]FIG. 15 illustrates an example of how the channel services managerand load module execution manager of FIG. 13 can support a channel;

[0310]FIG. 15A is an example of a channel header and channel detailrecords shown in FIG. 15;

[0311]FIG. 15B is a flowchart of an example of program control stepsthat may be performed by the FIG. 13 protected processing environment tocreate a channel;

[0312]FIG. 16 is a block diagram of an example of a secure data basestructure;

[0313]FIG. 17 is an illustration of an example of a logical objectstructure;

[0314]FIG. 18 shows an example of a stationary object structure;

[0315]FIG. 19 shows an example of a traveling object structure;

[0316]FIG. 20 shows an example of a content object structure;

[0317]FIG. 21 shows an example of an administrative object structure;

[0318]FIG. 22 shows an example of a method core structure;

[0319]FIG. 23 shows an example of a load module structure;

[0320]FIG. 24 shows an example of a User Data Element (UDE) and/orMethod Data Element (MDE) structure;

[0321] FIGS. 25A-25C show examples of “map meters”;

[0322]FIG. 26 shows an example of a permissions record (PERC) structure;

[0323]FIGS. 26A and 26B together show a more detailed example of apermissions record structure;

[0324]FIG. 27 shows an example of a shipping table structure;

[0325]FIG. 28 shows an example of a receiving table structure;

[0326]FIG. 29 shows an example of an administrative event log structure;

[0327]FIG. 30 shows an example inter-relationship between and use of theobject registration table, subject table and user rights table shown inthe FIG. 16 secure database;

[0328]FIG. 31 is a more detailed example of an object registration tableshown in FIG. 16;

[0329]FIG. 32 is a more detailed example of subject table shown in FIG.16;

[0330]FIG. 33 is a more detailed example of a user rights table shown inFIG. 16;

[0331]FIG. 34 shows a specific example of how a site record table andgroup record table may track portions of the secure database shown inFIG. 16;

[0332]FIG. 34A is an example of a FIG. 34 site record table structure;

[0333]FIG. 34B is an example of a FIG. 34 group record table structure;

[0334]FIG. 35 shows an example of a process for updating the securedatabase;

[0335]FIG. 36 shows an example of how new elements may be inserted intothe FIG. 16 secure data base;

[0336]FIG. 37 shows an example of how an element of the secure databasemay be accessed;

[0337]FIG. 38 is a flowchart example of how to protect a secure databaseelement;

[0338]FIG. 39 is a flowchart example of how to back up a securedatabase;

[0339]FIG. 40 is a flowchart example of how to recover a secure databasefrom a backup;

[0340] FIGS. 41A-41D are a set of examples showing how a “chain ofhandling and control” may be enabled using “reciprocal methods”;

[0341] FIGS. 42A-42D show an example of a “reciprocal” BUDGET method;

[0342] FIGS. 43A-43D show an example of a “reciprocal” REGISTER method;

[0343] FIGS. 44A-44C show an example of a “reciprocal” AUDIT method;

[0344] FIGS. 45-48 show examples of several methods being used togetherto control release of content or other information;

[0345] FIGS. 49, 49A-49F show an example OPEN method;

[0346] FIGS. 50, 50A-50F show an example of a READ method;

[0347] FIGS. 51, 51A-51F show an example of a WRITE method;

[0348]FIG. 52 shows an example of a CLOSE method;

[0349] FIGS. 53A-53B show an example of an EVENT method;

[0350]FIG. 53C shows an example of a BILLING method;

[0351]FIG. 54 shows an example of an ACCESS method;

[0352] FIGS. 55A-55B show examples of DECRYPT and ENCRYPT methods;

[0353]FIG. 56 shows an example of a CONTENT method;

[0354]FIGS. 57A and 57B show examples of EXTRACT and EMBED methods;

[0355]FIG. 58A shows an example of an OBSCURE method;

[0356]FIGS. 58B, 58C show examples of a FINGERPRINT method;

[0357]FIG. 59 shows an example of a DESTROY method;

[0358]FIG. 60 shows an example of a PANIC method;

[0359]FIG. 61 shows an example of a METER method;

[0360]FIG. 62 shows an example of a key “convolution” process;

[0361]FIG. 63 shows an example of how different keys may be generatedusing a key convolution process to determine a “true” key;

[0362]FIGS. 64 and 65 show an example of how protected processingenvironment keys may be initialized;

[0363]FIGS. 66 and 67 show example processes for decrypting informationcontained within stationary and traveling objects, respectively;

[0364]FIGS. 67A and 67B show example techniques for cracking asoftware-based protected processing environment;

[0365]FIG. 68 shows an example of how a protected processing environmentmay be initialized;

[0366]FIG. 69 shows an example of how firmware may be downloaded into aprotected processing environment;

[0367]FIG. 69A shows an example technique for distributing protectedprocessing environment software;

[0368] FIGS. 69B-69C show an example installation routine for installinga software-based protected processing environment;

[0369]FIG. 69D shows example techniques for embedding cryptographic keysat random locations within structure-based protected processingenvironment operational materials;

[0370]FIG. 69E shows example locations for PPE operational materialsrandom modifications and/or digital fingerprints;

[0371]FIG. 69F shows an example customized static storage layout for PPEoperational materials;

[0372]FIG. 69G shows example electronic appliance signature locations;

[0373]FIG. 69H shows example sequence dependent and independentprocesses;

[0374]FIGS. 69I and 69J show example static code and data storageorganizations;

[0375] FIGS. 69K-69L together show example steps for providing dynamicprotection mechanisms;

[0376]FIG. 69M shows an example initialization time check routine;

[0377]FIG. 69N shows an example time check routine;

[0378]FIG. 69O shows example time check data structures;

[0379]FIG. 70 shows an example of multiple VDE electronic appliancesconnected together with a network or other communications means;

[0380]FIG. 70A shows how content may be prepared for printing andencrypted inside a PPE, then decrypted inside a printer;

[0381]FIG. 70B shows how characters may be selected from slightlydifferent fonts in order to place an electronic fingerprint or watermarkinto printed output;

[0382]FIG. 70C shows how characters in a font may be permuted to rendera printed page unusable without the corresponding scrambled font;

[0383]FIG. 71 shows an example of a portable VDE electronic appliance;

[0384] FIGS. 72A-72D show examples of “pop-up” displays that may begenerated by the user notification and exception interface;

[0385]FIG. 73 shows an example of a “smart object”;

[0386]FIG. 74 shows an example of a process using “smart objects”;

[0387] FIGS. 75A-75D show examples of data structures used forelectronic negotiation;

[0388] FIGS. 75E-75F show example structures relating to an electronicagreement;

[0389] FIGS. 76A-76B show examples of electronic negotiation processes;

[0390]FIG. 77 shows a further example of a chain of handling andcontrol;

[0391]FIG. 78 shows an example of a VDE “repository”;

[0392] FIGS. 79-83 show an example illustrating a chain of handling andcontrol to evolve and transform VDE managed content and controlinformation;

[0393]FIG. 84 shows a further example of a chain of handling and controlinvolving several categories of VDE participants;

[0394]FIG. 85 shows a further example of a chain of distribution andhandling within an organization;

[0395]FIGS. 86 and 86A show a further example of a chain of handling andcontrol; and

[0396]FIG. 87 shows an example of a virtual silicon container model.

MORE DETAILED DESCRIPTION

[0397] FIGS. 1-7 and the discussion below provides an overview of someaspects of features provided by this invention. Following this overviewis a more technical “detail description” of example embodiments inaccordance with the invention.

[0398] Overview

[0399]FIG. 1 shows a “Virtual Distribution Environment” (“VDE”) 100 thatmay be provided in accordance with this invention. In FIG. 1, aninformation utility 200 connects to communications means 202 such astelephone or cable TV lines for example. Telephone or cable TV lines 202may be part of an “electronic highway” that carries electronicinformation from place to place. Lines 202 connect information utility200 to other people such as for example a consumer 208, an office 210, avideo production studio 204, and a publishing house 214. Each of thepeople connected to information utility 200 may be called a “VDEparticipant” because they can participate in transactions occurringwithin the virtual distribution environment 100.

[0400] Almost any sort of transaction you can think of can be supportedby virtual distribution environment 100. A few of many examples oftransactions that can be supported by virtual distribution environment100 include:

[0401] home banking and electronic payments;

[0402] electronic legal contracts;

[0403] distribution of “content” such as electronic printed matter,video, audio, images and computer programs; and

[0404] secure communication of private information such as medicalrecords and financial information.

[0405] Virtual distribution environment 100 is “virtual” because it doesnot require many of the physical “things” that used to be necessary toprotect rights, ensure reliable and predictable distribution, and ensureproper compensation to content creators and distributors. For example,in the past, information was distributed on records or disks that weredifficult to copy. In the past, private or secret content wasdistributed in sealed envelopes or locked briefcases delivered bycourier. To ensure appropriate compensation, consumers received goodsand services only after they handed cash over to a seller. Althoughinformation utility 200 may deliver information by transferring physical“things” such as electronic storage media, the virtual distributionenvironment 100 facilitates a completely electronic “chain of handlingand control.”

[0406] VDE Flexibility Supports Transactions

[0407] Information utility 200 flexibly supports many different kinds ofinformation transactions. Different VDE participants may define and/orparticipate in different parts of a transaction. Information utility 200may assist with delivering information about a transaction, or it may beone of the transaction participants.

[0408] For example, the video production studio 204 in the upperright-hand corner of FIG. 1 may create video/television programs. Videoproduction studio 204 may send these programs over lines 202, or may useother paths such as satellite link 205 and CD ROM delivery service 216.Video production studio 204 can send the programs directly to consumers206, 208, 210, or it can send the programs to information utility 200which may store and later send them to the consumers, for example.Consumers 206, 208, 210 are each capable of receiving and using theprograms created by video production studio 204—assuming, that is, thatthe video production studio or information utility 200 has arranged forthese consumers to have appropriate “rules and controls” (controlinformation) that give the consumers rights to use the programs.

[0409] Even if a consumer has a copy of a video program, she cannotwatch or copy the program unless she has “rules and controls” thatauthorize use of the program. She can use the program only as permittedby the “rules and controls.”

[0410] For example, video production studio 204 might release ahalf-hour exercise video in the hope that as many viewers as possiblewill view it. The video production studio 204 wishes to receive $2.00per viewing. Video production studio 204 may, through informationutility 200, make the exercise video available in “protected” form toall consumers 206, 208, 210. Video production studio 204 may alsoprovide “rules and controls” for the video. These “rules and controls”may specify for example:

[0411] (1) any consumer who has good credit of at least $2.00 based on acredit account with independent financial provider 212 (such asMastercard or VISA) may watch the video,

[0412] (2) virtual distribution environment 100 will “meter” each time aconsumer watches the video, and report usage to video production studio204 from time to time, and

[0413] (3) financial provider 212 may electronically collect payment($2.00) from the credit account of each consumer who watches the video,and transfer these payments to the video production studio 204.

[0414] Information utility 200 allows even a small video productionstudio to market videos to consumers and receive compensation for itsefforts. Moreover, the videos can, with appropriate payment to the videoproduction studio, be made available to other video publishers who mayadd value and/or act as repackagers or redistributors.

[0415]FIG. 1 also shows a publishing house 214. Publishing house 214 mayact as a distributor for an author 206. The publishing house 214 maydistribute rights to use “content” (such as computer software,electronic newspapers, the video produced by publishing house 214,audio, or any other data) to consumers such as office 210. The userights may be defined by “rules and controls” distributed by publishinghouse 216. Publishing house 216 may distribute these “rules andcontrols” with the content, but this is not necessary. Because thecontent can be used only by consumers that have the appropriate “rulesand controls,” content and its associated “rules and controls” may bedistributed at different times, in different ways, by different VDEparticipants. The ability of VDE to securely distribute and enforce“rules and controls” separately from the content they apply to providesgreat advantages.

[0416] Use rights distributed by publishing house 214 may, for example,permit office 210 to make and distribute copies of the content to itsemployees. Office 210 may act as a redistributor by extending a “chainof handling and control” to its employees. The office 210 may add ormodify “rules and controls” (consistent with the “rules and controls” itreceives from publishing house 214) to provide office-internal controlinformation and mechanisms. For example, office 210 may set a maximumusage budget for each individual user and/or group within the office, orit may permit only specified employees and/or groups to access certaininformation.

[0417]FIG. 1 also shows an information delivery service 216 deliveringelectronic storage media such as “CD ROM” disks to consumers 206. Eventhough the electronic storage media themselves are not deliveredelectronically by information utility 200 over lines 202, they are stillpart of the virtual distribution environment 100. The electronic storagemedia may be used to distribute content, “rules and controls,” or otherinformation.

[0418] Example of What's Inside Information Utility 200

[0419] “Information utility” 200 in FIG. 1 can be a collection ofparticipants that may act as distributors, financial clearinghouses, andadministrators. FIG. 1A, shows an example of what may be inside oneexample of information utility 200. Information utility participants 200a-200 g could each be an independent organization/business. There can beany number of each of participants 200 a-200 g. In this example,electronic “switch” 200 a connects internal parts of information utility200 to each other and to outside participants, and may also connectoutside participants to one another.

[0420] Information utility 200 may include a “transaction processor” 200b that processes transactions (to transfer electronic funds, forexample) based on requests from participants and/or report receiver 200e. It may also include a “usage analyst” 200 c that analyzes reportedusage information. A “report creator” 200 d may create reports based onusage for example, and may provide these reports to outside participantsand/or to participants within information utility 200. A “reportreceiver” 200 e may receive reports such as usage reports from contentusers. A “permissioning agent” 200 f may distribute “rules and controls”granting usage or distribution permissions based on a profile of aconsumer's credit worthiness, for example. An administrator 200 h mayprovide information that keeps the virtual distribution environment 100operating properly. A content and message storage 200 g may storeinformation for use by participants within or outside of informationutility 200.

[0421] Example of Distributing Content “Using a Chain of Handling andControl”

[0422] As explained above, virtual distribution environment 100 can beused to manage almost any sort of transaction. One type of importanttransaction that virtual distribution environment 100 may be used tomanage is the distribution or communication of “content” or otherimportant information. FIG. 2 more abstractly shows a “model” of how theFIG. 1 virtual distribution environment 100 may be used to provide a“chain of handling and control” for distributing content. Each of theblocks in FIG. 2 may correspond to one or more of the VDE participantsshown in FIG. 1.

[0423] In the FIG. 2 example, a VDE content creator 102 creates“content.” The content creator 102 may also specify “rules and controls”for distributing the content. These distribution-related “rules andcontrols” can specify who has permission to distribute the rights to usecontent, and how many users are allowed to use the content.

[0424] Arrow 104 shows the content creator 102 sending the “rules andcontrols” associated with the content to a VDE rights distributor 106(“distributor”) over an electronic highway 108 (or by some other pathsuch as an optical disk sent by a delivery service such as U.S. mail).The content can be distributed over the same or different path used tosend the “rules and controls.” The distributor 106 generates her own“rules and controls” that relate to usage of the content. Theusage-related “rules and controls” may, for example, specify what a usercan and can't do with the content and how much it costs to use thecontent. These usage-related “rules and controls” must be consistentwith the “rules and controls” specified by content creator 102.

[0425] Arrow 110 shows the distributor 106 distributing rights to usethe content by sending the content's “rules and controls” to a contentuser 112 such as a consumer. The content user 112 uses the content inaccordance with the usage-related “rules and controls.”

[0426] In this FIG. 2 example, information relating to content use is,as shown by arrow 114, reported to a financial clearinghouse 116. Basedon this “reporting,” the financial clearinghouse 116 may generate a billand send it to the content user 112 over a “reports and payments”network 118. Arrow 120 shows the content user 112 providing payments forcontent usage to the financial clearinghouse 116. Based on the reportsand payments it receives, the financial clearinghouse 116 may providereports and/or payments to the distributor 106. The distributor 106 may,as shown by arrow 122, provide reports and/or payments to the contentcreator 102. The clearinghouse 116 may provide reports and paymentsdirectly to the creator 102. Reporting and/or payments may be donedifferently. For example, clearinghouse 116 may directly or through anagent, provide reports and/or payments to each of VDE content creators102, and rights distributor 106, as well as reports to content user 112.

[0427] The distributor 106 and the content creator 102 may be the sameperson, or they may be different people. For example, a musicalperforming group may act as both content creator 102 and distributor 106by creating and distributing its own musical recordings. As anotherexample, a publishing house may act as a distributor 106 to distributerights to use works created by an author content creator 102. Contentcreators 102 may use a distributor 106 to efficiently manage thefinancial end of content distribution.

[0428] The “financial clearinghouse” 116 shown in FIG. 2 may also be a“VDE administrator.” Financial clearinghouse 116 in its VDEadministrator role sends “administrative” information to the VDEparticipants. This administrative information helps to keep the virtualdistribution environment 100 operating properly. The “VDE administrator”and financial clearinghouse roles may be performed by different peopleor companies, and there can be more than one of each.

[0429] More about “Rules and Controls”

[0430] The virtual distribution environment 100 prevents use ofprotected information except as permitted by the “rules and controls”(control information). For example, the “rules and controls” shown inFIG. 2 may grant specific individuals or classes of content users 112“permission” to use certain content. They may specify what kinds ofcontent usage are permitted, and what kinds are not. They may specifyhow content usage is to be paid for and how much it costs. As anotherexample, “rules and controls” may require content usage information tobe reported back to the distributor 106 and/or content creator 102.

[0431] Every VDE participant in “chain of handling and control” isnormally subject to “rules and controls.” “Rules and controls” definethe respective rights and obligations of each of the various VDEparticipants. “Rules and controls” provide information and mechanismsthat may establish interdependencies and relationships between theparticipants. “Rules and controls” are flexible, and permit “virtualdistribution environment” 100 to support most “traditional” businesstransactions. For example:

[0432] “Rules and controls” may specify which financial clearinghouse(s)116 may process payments,

[0433] “Rules and controls” may specify which participant(s) receivewhat kind of usage report, and

[0434] “Rules and controls” may specify that certain information isrevealed to certain participants, and that other information is keptsecret from them.

[0435] “Rules and controls” may self limit if and how they may bechanged. Often, “rules and controls” specified by one VDE participantcannot be changed by another VDE participant. For example, a contentuser 112 generally can't change “rules and controls” specified by adistributor 106 that require the user to pay for content usage at acertain rate. “Rules and controls” may “persist” as they pass through a“chain of handling and control,” and may be “inherited” as they arepassed down from one VDE participant to the next.

[0436] Depending upon their needs, VDE participants can specify thattheir “rules and controls” can be changed under conditions specified bythe same or other “rules and controls.” For example, “rules andcontrols” specified by the content creator 102 may permit thedistributor 106 to “mark up” the usage price just as retail stores “markup” the wholesale price of goods. FIG. 2A shows an example in whichcertain “rules and controls” persist unchanged from content creator 102to content user 112; other “rules and controls” are modified or deletedby distributor 106; and still other “rules and controls” are added bythe distributor.

[0437] “Rules and controls” can be used to protect the content user'sprivacy by limiting the information that is reported to other VDEparticipants. As one example, “rules and controls” can cause contentusage information to be reported anonymously without revealing contentuser identity, or it can reveal only certain information to certainparticipants (for example, information derived from usage) withappropriate permission, if required. This ability to securely controlwhat information is revealed and what VDE participant(s) it is revealedto allows the privacy rights of all VDE participants to be protected.

[0438] “Rules ad Contents” Can Be Separately Delivered

[0439] As mentioned above, virtual distribution environment 100“associates” content with corresponding “rules and controls,” andprevents the content from being used or accessed unless a set ofcorresponding “rules and controls” is available. The distributor 106doesn't need to deliver content to control the content's distribution.The preferred embodiment can securely protect content by protectingcorresponding, usage enabling “rules and controls” against unauthorizeddistribution and use.

[0440] In some examples, “rules and controls” may travel with thecontent they apply to. Virtual distribution environment 100 also allows“rules and controls” to be delivered separately from content. Since noone can use or access protected content without “permission” fromcorresponding “rules and controls,” the distributor 106 can control useof content that has already been (or will in the future be) delivered.“Rules and controls” may be delivered over a path different from the oneused for content delivery. “Rules and controls” may also be delivered atsome other time. The content creator 102 might deliver content tocontent user 112 over the electronic highway 108, or could make thecontent available to anyone on the highway. Content may be used at thetime it is delivered, or it may be stored for later use or reuse.

[0441] The vial distribution environment 100 also allows payment andreporting means to be delivered separately. For example, the contentuser 112 may have a virtual “credit card” that extends credit (up to acertain limit) to pay for usage of any content. A “credit transaction”can take place at the user's site without requiring any “online”connection or further authorization. This invention can be used to helpsecurely protect the vial “credit card” against unauthorized use.

[0442] “Rules and Contents” Define Processes

[0443]FIG. 3 shows an example of an overall process based on “rules andcontrols.” It includes an “events” process 402, a meter process 404, abilling process 406, and a budget process 408. Not all of the processesshown in FIG. 3 will be used for every set of “rules and controls.”

[0444] The “events process” 402 detects things that happen (“events”)and determines which of those “events” need action by the other“processes.” The “events” may include, for example, a request to usecontent or generate a usage permission. Some events may need additionalprocessing, and others may not. Whether an “event” needs more processingdepends on the “rules and controls” corresponding to the content. Forexample, a user who lacks permission will not have her request satisfied(“No Go”). As another example, each user request to turn to a new pageof an electronic book may be satisfied (“Go”), but it may not benecessary to meter, bill or budget those requests. A user who haspurchased a copy of a novel may be permitted to open and read the novelas many times as she wants to without any further metering, billing orbudgeting. In this simple example, the “event process” 402 may requestmetering, billing and/or budgeting processes the first time the userasks to open the protected novel (so the purchase price can be chargedto the user), and treat all later requests to open the same novel as“insignificant events.” Other content (for example, searching anelectronic telephone directory) may require the user to pay a fee foreach access.

[0445] “Meter” process 404 keeps track of events, and may report usageto distributor 106 and/or other appropriate VDE participant(s). FIG. 4shows that process 404 can be based on a number of different factorssuch as:

[0446] (a) type of usage to charge for,

[0447] (b) what kind of unit to base charges on,

[0448] (c) how much to charge per unit,

[0449] (d) when to report, and

[0450] (e) how to pay.

[0451] These factors may be Specified by the “Rules and Controls” thatcontrol the meter process.

[0452] Billing process 406 determines how much to charge for events. Itrecords and reports payment information.

[0453] Budget process 408 limits how much content usage is permitted.For example, budget process 408 may limit the number of times contentmay be accessed or copied, or it may limit the number of pages or otheramount of content that can be used based on, for example, the number ofdollars available in a credit account. Budget process 408 records andreports financial and other transaction information associated with suchlimits.

[0454] Content may be supplied to the user once these processes havebeen successfully performed.

[0455] Containers and “Objects”

[0456]FIG. 5A shows how the virtual distribution environment 100, in apreferred embodiment, may package information elements (content) into a“container” 302 so the information can't be accessed except as providedby its “rules and controls.” Normally, the container 302 is electronicrather than physical. Electronic container 302 in one example comprises“digital” information having a well defined structure. Container 302 andits contents can be called an “object 300.”

[0457] The FIG. 5A example shows items “within” and enclosed bycontainer 302. However, container 302 may “contain” items without thoseitems actually being stored within the container. For example, thecontainer 302 may reference items that are available elsewhere such asin other containers at remote sites. Container 302 may reference itemsavailable at different times or only during limited times. Some itemsmay be too large to store within container 302. Items may, for example,be delivered to the user in the form of a “live feed” of video at acertain time. Even then, the container 302 “contains” the live feed (byreference) in this example.

[0458] Container 302 may contain information content 304 in electronic(such as “digital”) form. Information content 304 could be the text of anovel, a picture, sound such as a musical performance or a reading, amovie or other video, computer software, or just about any other kind ofelectronic information you can think of. Other types of “objects” 300(such as “administrative objects”) may contain “administrative” or otherinformation instead of or in addition to information content 304.

[0459] In the FIG. 5A example, container 302 may also contain “rules andcontrols” in the form of:

[0460] (a) a “permissions record” 808;

[0461] (b) “budgets” 308; and

[0462] (c) “other methods” 1000.

[0463]FIG. 5B gives some additional detail about permissions record 808,budgets 308 and other methods 1000. The “permissions record” 808specifies the rights associated with the object 300 such as, forexample, who can open the container 302, who can use the object'scontents, who can distribute the object, and what other controlmechanisms must be active. For example, permissions record 808 mayspecify a user's rights to use, distribute and/or administer thecontainer 302 and its content. Permissions record 808 may also specifyrequirements to be applied by the budgets 308 and “other methods” 1000.Permissions record 808 may also contain security related informationsuch as scrambling and descrambling “keys.”

[0464] “Budgets” 308 shown in FIG. 5B are a special type of “method”1000 that may specify, among other things, limitations on usage ofinformation content 304, and how usage will be paid for. Budgets 308 canspecify, for example, how much of the total information content 304 canbe used and/or copied. The methods 310 may prevent use of more than theamount specified by a specific budget.

[0465] “Other methods” 1000 define basic operations used by “rules andcontrols.” Such “methods” 1000 may include, for example, how usage is tobe “metered,” if and how content 304 and other information is to bescrambled and descrambled, and other processes associated with handlingand controlling information content 304. For example, methods 1000 mayrecord the identity of anyone who opens the electronic container 302,and can also control how information content is to be charged based on“metering.” Methods 1000 may apply to one or several differentinformation contents 304 and associated containers 302, as well as toall or specific portions of information content 304.

[0466] Secure Processing Unit (SPU)

[0467] The “VDE participants” may each have an “electronic appliance.”The appliance may be or contain a computer. The appliances maycommunicate over the electronic highway 108. FIG. 6 shows a secureprocessing unit (“SPU”) 500 portion of the “electronic appliance” usedin this example by each VDE participant. SPU, 500 processes informationin a secure processing environment 503, and stores important informationsecurely. SPU 500 may be emulated by software operating in a hostelectronic appliance.

[0468] SPU 500 is enclosed within and protected by a “tamper resistantsecurity barrier” 502. Security barrier 502 separates the secureenvironment 503 from the rest of the world. It prevents information andprocesses within the secure environment 503 from being observed,interfered with and leaving except under appropriate secure conditions.Barrier 502 also controls external access to secure resources, processesand information within SPU 500. In one example, tamper resistantsecurity barrier 502 is formed by security features such as“encryption,” and hardware that detects tampering and/or destroyssensitive information within secure environment 503 when tampering isdetected.

[0469] SPU 500 in this example is an integrated circuit (“IC”) “chip”504 including “hardware” 506 and “firmware” 508. SPU 500 connects to therest of the electronic appliance through an “appliance link” 510. SPU“firmware” 508 in this example is “software” such as a “computerprogram(s)” “embedded” within chip 504. Firmware 508 makes the hardware506 work. Hardware 506 preferably contains a processor to performinstructions specified by firmware 508. “Hardware” 506 also containslong-term and short-term memories to store information securely so itcan't be tampered with. SPU 500 may also have a protected clock/calendarused for timing events. The SPU hardware 506 in this example may includespecial purpose electronic circuits that are specially designed toperform certain processes (such as “encryption” and “decryption”)rapidly and efficiently.

[0470] The particular context in which SPU 500 is being used willdetermine how much processing capabilities SPU 500 should have. SPUhardware 506, in this example, provides at least enough processingcapabilities to support the secure parts of processes shown in FIG. 3.In some contexts, the functions of SPU 500 may be increased so the SPUcan perform all the electronic appliance processing, and can beincorporated into a general purpose processor. In other contexts, SPU500 may work alongside a general purpose processor, and therefore onlyneeds to have enough processing capabilities to handle secure processes.

[0471] VDE Electronic Appliance and “Rights Operating System”

[0472]FIG. 7 shows an example of an electronic appliance 600 includingSPU 500. Electronic appliance 600 may be practically any kind ofelectrical or electronic device, such as:

[0473] a computer

[0474] a T.V. “set top” control box

[0475] a pager

[0476] a telephone

[0477] a sound system

[0478] a video reproduction system

[0479] a video game player

[0480] a “smart” credit card

[0481] Electronic appliance 600 in this example may include a keyboardor keypad 612, a voice recognizer 613, and a display 614. A human usercan input commands through keyboard 612 and/or voice recognizer 613, andmay view information on display 614. Appliance 600 may communicate withthe outside world through any of the connections/devices normally usedwithin an electronic appliance. The connections/devices shown along thebottom of the drawing are examples:

[0482] a “modem” 618 or other telecommunications link;

[0483] a CD ROM disk 620 or other storage medium or device;

[0484] a printer 622;

[0485] broadcast reception 624;

[0486] a document scanner 626; and

[0487] a “cable” 628 connecting the appliance with a “network.”

[0488] Virtual distribution environment 100 provides a “rights operatingsystem” 602 that manages appliance 600 and SPU 500 by controlling theirhardware resources. The operating system 602 may also support at leastone “application” 608. Generally, “application” 608 is hardware and/orsoftware specific to the context of appliance 600. For example, ifappliance 600 is a personal computer, then “application” 608 could be aprogram loaded by the user, for instance, a word processor, acommunications system or a sound recorder. If appliance 600 is atelevision controller box, then application 608 might be hardware orsoftware that allows a user to order videos on demand and perform otherfunctions such as fast forward and rewind. In this example, operatingsystem 602 provides a standardized, well defined, generalized“interface” that could support and work with many different“applications” 608.

[0489] Operating system 602 in this example provides “rights andauditing operating system functions” 604 and “other operating systemfunctions” 606. The “rights and auditing operating system functions” 604securely handle tasks that relate to virtual distribution environment100. SPU 500 provides or supports many of the security functions of the“rights and auditing operating system functions” 402. The “otheroperating system functions” 606 handle general appliance functions.Overall operating system 602 may be designed from the beginning toinclude the “rights and auditing operating system functions” 604 plusthe “other operating system functions” 606, or the “rights and auditingoperating system functions” may be an add-on to a preexisting operatingsystem providing the “other operating system functions.”

[0490] “Rights operating system” 602 in this example can work with manydifferent types of appliances 600. For example, it can work with largemainframe computers, “minicomputers” and “microcomputers” such aspersonal computers and portable computing devices. It can also work incontrol boxes on the top of television sets, small portable “pagers,”desktop radios, stereo sound systems, telephones, telephone switches, orany other electronic appliance. This ability to work on big appliancesas well as little appliances is called “scalable.” A “scalable”operating system 602 means that there can be a standardized interfaceacross many different appliances performing a wide variety of tasks.

[0491] The “rights operating system functions” 604 are “services-based”in this example. For example, “rights operating system functions” 604handle summary requests from application 608 rather than requiring theapplication to always make more detailed “subrequests” or otherwise getinvolved with the underlying complexities involved in satisfying asummary request. For example, application 608 may simply ask to readspecified information; “rights operating system functions” 604 can thendecide whether the desired information is VDE-protected content and, ifit is, perform processes needed to make the information available. Thisfeature is called “transparency.” “Transparency” makes tasks easy forthe application 608. “Rights operating system functions” 604 can supportapplications 608 that “know” nothing about virtual distributionenvironment 100. Applications 608 that are “aware” of virtualdistribution environment 100 may be able to make more detailed use ofvirtual distribution environment 100.

[0492] In this example, “rights operating system functions” 604 are“event driven”. Rather than repeatedly examining the state of electronicappliance 600 to determine whether a condition has arisen, the “rightsoperating system functions” 604 may respond directly to “events” or“happenings” within appliance 600.

[0493] In this example, some of the services performed by “rightsoperating system functions” 604 may be extended based on additional“components” delivered to operating system 602. “Rights operating systemfunctions” 604 can collect together and use “components” sent bydifferent participants at different times. The “components” help to makethe operating system 602 “scalable.” Some components can change howservices work on little appliances versus how they work on bigappliances (e.g., multi-user). Other components are designed to workwith specific applications or classes of applications (e.g., some typesof meters and some types of budgets).

[0494] Electronic Appliance 600

[0495] An electronic appliance 600 provided by the preferred embodimentmay, for example, be any electronic apparatus that contains one or moremicroprocessors and/or microcontrollers and/or other devices whichperform logical and/or mathematical calculations. This may includecomputers; computer terminals; device controllers for use withcomputers; peripheral devices for use with computers; digital displaydevices; televisions; video and audio/video projection systems; channelselectors and/or decoders for use with broadcast and/or cabletransmissions; remote control devices; video and/or audio recorders;media players including compact disc players, videodisc players and tapeplayers; audio and/or video amplifiers; virtual reality machines;electronic game players; multimedia players; radios; telephones;videophones; facsimile machines; robots; numerically controlled machinesincluding machine tools and the like; and other devices containing oneor more microcomputers and/or microcontrollers and/or other CPUs,including those not yet in existence.

[0496]FIG. 8 shows an example of an electronic appliance 600. Thisexample of electronic appliance 600 includes a system bus 653. In thisexample, one or more conventional general purpose central processingunits (“CPUs”) 654 are connected to bus 653. Bus 653 connects CPU(s) 654to RAM 656, ROM 658, and I/O controller 660. One or more SPUs 500 mayalso be connected to system bus 653. System bus 653 may permit SPU(s)500 to communicate with CPU(s) 654, and also may allow both the CPU(s)and the SPU(s) to communicate (e.g., over shared address and data lines)with RAM 656, ROM 658 and I/O controller 660. A power supply 659 mayprovide power to SPU 500, CPU 654 and the other system components shown.

[0497] In the example shown, I/O controller 660 is connected tosecondary storage device 652, a keyboard/display 612,614, acommunications controller 666, and a backup storage device 668. Backupstorage device 668 may, for example, store information on mass mediasuch as a tape 670, a floppy disk, a removable memory card, etc.Communications controller 666 may allow electronic appliance 600 tocommunicate with other electronic appliances via network 672 or othertelecommunications links. Different electronic appliances 600 mayinteroperate even if they use different CPUs and different instances ofROS 602, so long as they typically use compatible communicationprotocols and/or security methods. In this example, I/O controller 660permits CPU 654 and SPU 500 to read from and write to secondary storage662, keyboard/display 612, 614, communications controller 666, andbackup storage device 668.

[0498] Secondary storage 662 may comprise the same one or morenon-secure secondary storage devices (such as a magnetic disk and aCD-ROM drive as one example) that electronic appliance 600 uses forgeneral secondary storage functions. In some implementations, part orall of secondary storage 652 may comprise a secondary storage device(s)that is physically enclosed within a secure enclosure. However, since itmay not be practical or cost-effective to physically secure secondarystorage 652 in many implementations, secondary storage 652 may be usedto store information in a secure manner by encrypting information beforestoring it in secondary storage 652. If information is encrypted beforeit is stored, physical access to secondary storage 652 or its contentsdoes not readily reveal or compromise the information.

[0499] Secondary storage 652 in this example stores code and data usedby CPU 654 and/or SPU 500 to control the overall operation of electronicappliance 600. For example, FIG. 8 shows that “Rights Operating System”(“ROS”) 602 (including a portion 604 of ROS that provides VDE functionsand a portion 606 that provides other OS functions) shown in FIG. 7 maybe stored on secondary storage 652. Secondary storage 652 may also storeone or more VDE objects 300. FIG. 8 also shows that the secure files 610shown in FIG. 7 may be stored on secondary storage 652 in the form of a“secure database” or management file system 610. This secure database610 may store and organize information used by ROS 602 to perform VDEfunctions 604. Thus, the code that is executed to perform VDE and otherOS functions 604, 606, and secure files 610 (as well as VDE objects 300)associated with those functions may be stored in secondary storage 652.Secondary storage 652 may also store “other information” 673 such as,for example, information used by other operating system functions 606for task management, non-VDE files, etc. Portions of the elementsindicated in secondary storage 652 may also be stored in ROM 658, solong as those elements do not require changes (except when ROM 658 isreplaced). Portions of ROS 602 in particular may desirably be includedin ROM 658 (e.g., “bootstrap” routines, POST routines, etc. for use inestablishing an operating environment for electronic appliance 600 whenpower is applied).

[0500]FIG. 8 shows that secondary storage 652 may also be used to storecode (“application programs”) providing user application(s) 608 shown inFIG. 7. FIG. 8 shows that there may be two general types of applicationprograms 608: “VDE aware” applications 608 a, and Non-VDE awareapplications 608 b. VDE aware applications 608 a may have been at leastin part designed specifically with VDE 100 in mind to access and takedetailed advantage of VDE functions 604. Because of the “transparency”features of ROS 602, non-VDE aware applications 608 b (e.g.,applications not specifically designed for VDE 100) can also access andtake advantage of VDE functions 604.

[0501] Secure Processing Unit 500

[0502] Each VDE node or other electronic appliance 600 in the preferredembodiment may include one or more SPUs 500. SPUs 500 may be used toperform all secure processing for VDE 100. For example, SPU 500 is usedfor decrypting (or otherwise unsecuring) VDE protected objects 300. Itis also used for managing encrypted and/or otherwise securedcommunication (such as by employing authentication and/orerror-correction validation of information). SPU 500 may also performsecure data management processes including governing usage of, auditingof, and where appropriate, payment for VDE objects 300 (through the useof prepayments, credits, real-time electronic debits from bank accountsand/or VDE node currency token deposit accounts). SPU 500 may performother transactions related to such VDE objects 300.

[0503] SPU Physical Packaging and Security Barrier 502

[0504] As shown FIG. 6, in the preferred embodiment, an SPU 500 may beimplemented as a single integrated circuit “chip” 505 to provide asecure processing environment in which confidential and/or commerciallyvaluable information can be safely processed, encrypted and/ordecrypted. IC chip 505 may, for example, comprise a small semiconductor“die” about the size of a thumbnail. This semiconductor die may includesemiconductor and metal conductive pathways. These pathways define thecircuitry, and thus the functionality, of SPU 500. Some of thesepathways are electrically connected to the external “pins” 504 of thechip 505.

[0505] As shown in FIGS. 6 and 9, SPU 500 may be surrounded by atamper-resistant hardware security barrier 502. Part of this securitybarrier 502 is formed by a plastic or other package in which an SPU“die” is encased. Because the processing occurring within, andinformation stored by, SPU 500 are not easily accessible to the outsideworld, they are relatively secure from unauthorized access andtampering. All signals cross barrier 502 through a secure, controlledpath provided by BIU 530 that restricts the outside world's access tothe internal components within SPU 500. This secure, controlled pathresists attempts from the outside world to access secret information andresources within SPU 500.

[0506] It is possible to remove the plastic package of an IC chip andgain access to the “die.” It is also possible to analyze and “reverseengineer” the “die” itself (e.g., using various types of logic analyzersand microprobes to collect and analyze signals on the die while thecircuitry is operating, using acid etching or other techniques to removesemiconductor layers to expose other layers, viewing and photographingthe die using an electron microscope, etc.) Although no system orcircuit is absolutely impervious to such attacks, SPU barrier 502 mayinclude additional hardware protections that make successful attacksexceedingly costly and time consuming. For example, ion implantationand/or other fabrication techniques may be used to make it verydifficult to visually discern SPU die conductive pathways, and SPUinternal circuitry may be fabricated in such a way that it“self-destructs” when exposed to air and/or light. SPU 500 may storesecret information in internal memory that loses its contents when poweris lost. Circuitry may be incorporated within SPU 500 that detectsmicroprobing or other tampering, and self-destructs (or destroys otherparts of the SPU) when tampering is detected. These and otherhardware-based physical security techniques contribute totamper-resistant hardware security barrier 502.

[0507] To increase the security of security barrier 502 even further, itis possible to encase or include SPU 500 in one or more further physicalenclosures such as, for example: epoxy or other “potting compound”;further module enclosures including additional self-destruct,self-disabling or other features activated when tampering is detected;further modules providing additional security protections such asrequiring password or other authentication to operate; and the like. Inaddition, further layers of metal may be added to the die to complicateacid etching, micro probing, and the like; circuitry designed to“zeroize” memory may be included as an aspect of self-destructprocesses; the plastic package itself may be designed to resist chemicalas well as physical “attacks”; and memories internal to SPU 500 may havespecialized addressing and refresh circuitry that “shuffles” thelocation of bits to complicate efforts to electrically determine thevalue of memory locations. These and other techniques may contribute tothe security of barrier 502.

[0508] In some electronic appliances 600, SPU 500 may be integratedtogether with the device microcontroller or equivalent or with a deviceI/O or communications microcontroller into a common chip (or chip set)505. For example, in one preferred embodiment, SPU 500 may be integratedtogether with one or more other CPU(s) (e.g., a CPU 654 of an electronicappliance) in a single component or package. The other CPU(s) 654 may beany centrally controlling logic arrangement, such as for example, amicroprocessor, other microcontroller, and/or array or other parallelprocessor. This integrated configuration may result in lower overallcost, smaller overall size, and potentially faster interaction betweenan SPU 500 and a CPU 654. Integration may also provide widerdistribution if an integrated SPU/CPU component is a standard feature ofa widely distributed microprocessor line. Merging an SPU 500 into a mainCPU 654 of an electronic appliance 600 (or into another appliance orappliance peripheral microcomputer or other microcontroller) maysubstantially reduce the overhead cost of implementing VDE 100.Integration considerations may include cost of implementation, cost ofmanufacture, desired degree of security, and value of compactness.

[0509] SPU 500 may also be integrated with devices other than CPUs. Forexample, for video and multimedia applications, some performance and/orsecurity advantages (depending on overall design) could result fromintegrating an SPU 500 into a video controller chip or chipset. SPU 500can also be integrated directly into a network communications chip orchipset or the like. Certain performance advantages in high speedcommunications applications may also result from integrating an SPU 500with a modem chip or chipset. This may facilitate incorporation of anSPU 500 into communication appliances such as stand-alone fax machines.SPU 500 may also be integrated into other peripheral devices, such asCD-ROM devices, set-top cable devices, game devices, and a wide varietyof other electronic appliances that use, allow access to, performtransactions related to, or consume, distributed information.

[0510] SPU 500 Internal Architecture

[0511]FIG. 9 is a detailed diagram of the internal structure within anexample of SPU 500. SPU 500 in this example includes a singlemicroprocessor 520 and a limited amount of memory configured as ROM 532and RAM 534. In more detail, this example of SPU 500 includesmicroprocessor 520, an encrypt/decrypt engine 522, a DMK controller 526,a real-time clock 528, a bus interface unit (“BIU”) 530, a read onlymemory (ROM) 532, a random access memory (RAM) 534, and a memorymanagement unit (“MMU”) 540. DMA controller 526 and MMU 540 areoptional, but the performance of SPU 500 may suffer if they are notpresent. SPU 500 may also include an optional pattern matching engine524, an optional random number generator 542, an optional arithmeticaccelerator circuit 544, and optional compression/decompression circuit546. A shared address/data bus arrangement 536 may transfer informationbetween these various components under control of microprocessor 520and/or DMA controller 526. Additional or alternate dedicated paths 538may connect microprocessor 520 to the other components (e.g.,encrypt/decrypt engine 522 via line 538 a, real-time clock 528 via line538 b, bus interface unit 530 via line 538 c, DMA controller via line538 d, and memory management unit (MMU) 540 via line 538 e).

[0512] The following section discusses each of these SPU components inmore detail.

[0513] Microprocessor 520

[0514] Microprocessor 520 is the “brain” of SPU 500. In this example, itexecutes a sequence of steps specified by code stored (at leasttemporarily) within ROM 532 and/or RAM 534. Microprocessor 520 in thepreferred embodiment comprises a dedicated central processingarrangement (e.g., a RISC and/or CISC processor unit, a microcontroller,and/or other central processing means or, less desirably in mostapplications, process specific dedicated control logic) for executinginstructions stored in the ROM 532 and/or other memory. Microprocessor520 may be separate elements of a circuitry layout, or may be separatepackages within a secure SPU 500.

[0515] In the preferred embodiment, microprocessor 520 normally handlesthe most security sensitive aspects of the operation of electronicappliance 600. For example, microprocessor 520 may manage VDEdecrypting, encrypting, certain content and/or appliance usage controlinformation, keeping track of usage of VDE secured content, and otherVDE usage control related functions.

[0516] Stored in each SPU 500 and/or electronic appliance secondarymemory 652 may be, for example, an instance of ROS 602 software,application programs 608, objects 300 containing VDE controlled propertycontent and related information, and management database 610 that storesboth information associated with objects and VDE control information.ROS 602 includes software intended for execution by SPU microprocessor520 for, in part, controlling usage of VDE related objects 300 byelectronic appliance 600. As will be explained, these SPU programsinclude “load modules” for performing basic control functions. Thesevarious programs and associated data are executed and manipulatedprimarily by microprocessor 520.

[0517] Real Time Clock (RTC) 528

[0518] In the preferred embodiment, SPU 500 includes a real time clockcircuit (“RTC”) 528 that serves as a reliable, tamper resistant timebase for the SPU. RTC 528 keeps track of time of day and date (e.g.,month, day and year) in the preferred embodiment, and thus may comprisea combination calendar and clock. A reliable time base is important forimplementing time based usage metering methods, “time aged decryptionkeys,” and other time based SPU functions.

[0519] The RTC 528 must receive power in order to operate. Optimally,the RTC 528 power source could comprise a small battery located withinSPU 500 or other secure enclosure. However, the RTC 528 may employ apower source such as an externally located battery that is external tothe SPU 500. Such an externally located battery may provide relativelyuninterrupted power to RTC 528. and may also maintain as non-volatile atleast a portion of the otherwise volatile RAM 534 within SPU 500.

[0520] In one implementation, electronic appliance power supply 659 isalso used to power SPU 500. Using any external power supply as the onlypower source for RTC 528 may significantly reduce the usefulness of timebased security techniques unless, at minimum, SPU 500 recognizes anyinterruption (or any material interruption) of the supply of externalpower, records such interruption, and responds as may be appropriatesuch as disabling the ability of the SPU 500 to perform certain or allVDE processes. Recognizing a power interruption may, for example, beaccomplished by employing a circuit which is activated by power failure.The power failure sensing circuit may power another circuit thatincludes associated logic for recording one or more power fail events.Capacitor discharge circuitry may provide the necessary temporary powerto operate this logic. In addition or alternatively, SPU 500 may fromtime to time compare an output of RTC 528 to a clock output of a hostelectronic appliance 600, if available. In the event a discrepancy isdetected, SPU 500 may respond as appropriate, including recording thediscrepancy and/or disabling at least some portion of processesperformed by SPU 500 under at least some circumstances.

[0521] If a power failure and/or RTC 528 discrepancy and/or other eventindicates the possibility of tampering, SPU 500 may automaticallydestroy, or render inaccessible without privileged intervention, one ormore portions of sensitive information it stores, such as executionrelated information and/or encryption key related information. Toprovide further SPU operation, such destroyed information would have tobe replaced by a VDE clearinghouse, administrator and/or distributor, asmay be appropriate. This may be achieved by remotely downloading updateand/or replacement data and/or code. In the event of a disabling and/ordestruction of processes and/or information as described above, theelectronic appliance 600 may require a secure VDE communication with anadministrator, clearinghouse, and/or distributor as appropriate in orderto reinitialize the RTC 528. Some or all secure SPU 500 processes maynot operate until then.

[0522] It may be desirable to provide a mechanism for setting and/orsynchronizing RTC 528. In the preferred embodiment, when communicationoccurs between VDE electronic appliance 600 and another VDE appliance,an output of RTC 528 may be compared to a controlled RTC 528 output timeunder control of the party authorized to be “senior” and controlling. Inthe event of a discrepancy, appropriate action may be taken, includingresetting the RTC 528 of the “junior” controlled participant in thecommunication.

[0523] SPU Encrypt/Decrypt Engine 522

[0524] In the preferred embodiment, SPU encrypt/decrypt engine 522provides special purpose hardware (e.g., a hardware state machine) forrapidly and efficiently encrypting and/or decrypting data. In someimplementations, the encrypt/decrypt functions may be performed insteadby microprocessor 520 under software control, but providing specialpurpose encrypt/decrypt hardware engine 522 will, in general, provideincreased performance. Microprocessor 520 may, if desired, comprise acombination of processor circuitry and dedicated encryption/decryptionlogic that may be integrated together in the same circuitry layout so asto, for example, optimally share one or more circuit elements.

[0525] Generally, it is preferable that a computationally efficient buthighly secure “bulk” encryption/decryption technique should be used toprotect most of the data and objects handled by SPU 500. It ispreferable that an extremely secure encryption/decryption technique beused as an aspect of authenticating the identity of electronicappliances 600 that are establishing a communication channel andsecuring any transferred permission, method, and administrativeinformation. In the preferred embodiment, the encrypt/decrypt engine 522includes both a symmetric key encryption/decryption circuit (e.g. DES,Skipjack/Clipper, IDEA, RC-2, RC-4, etc.) and an antisymmetric(asymmetric) or Public Key (“PK”) encryption/decryption circuit. Thepublic/private key encryption/decryption circuit is used principally asan aspect of secure communications between an SPU 500 and VDEadministrators, or other electronic appliances 600, that is between VDEsecure subsystems. A symmetric encryption/decryption circuit may be usedfor “bulk” encrypting and decrypting most data stored in secondarystorage 662 of electronic appliance 600 in which SPU 500 resides. Thesymmetric key encryption/decryption circuit may also be used forencrypting and decrypting content stored within VDE objects 300.

[0526] DES or public/private key methods may be used for all encryptionfunctions. In alternate embodiments, encryption and decryption methodsother than the DES and public/private key methods could be used for thevarious encryption related functions. For instance, other types ofsymmetric encryption/decryption techniques in which the same key is usedfor encryption and decryption could be used in place of DES encryptionand decryption. The preferred embodiment can support a plurality ofdecryption/encryption techniques using multiple dedicated circuitswithin encrypt/decrypt engine 522 and/or the processing arrangementwithin SPU 500.

[0527] Pattern Matching Engine 524

[0528] Optional pattern matching engine 524 may provide special purposehardware for performing pattern matching functions. One of the functionsSPU 500 may perform is to validate/authenticate VDE objects 300 andother items. Validation/authentication often involves comparing longdata strings to determine whether they compare in a predetermined way.In addition, certain forms of usage (such as logical and/or physical(contiguous) relatedness of accessed elements) may require searchingpotentially long strings of data for certain bit patterns or othersignificant pattern related metrics. Although pattern matching can beperformed by SPU microprocessor 520 under software control, providingspecial purpose hardware pattern matching engine 524 may speed up thepattern matching process.

[0529] Compression/Decompression Engine 546

[0530] An optional compression/decompression engine 546 may be providedwithin an SPU 500 to, for example, compress and/or decompress contentstored in, or released from, VDE objects 300. Compression/decompressionengine 546 may implement one or more compression algorithms usinghardware circuitry to improve the performance ofcompression/decompression operations that would otherwise be performedby software operating on microprocessor 520, or outside SPU 500.Decompression is important in the release of data such as video andaudio that is usually compressed before distribution and whosedecompression speed is important. In some cases, information that isuseful for usage monitoring purposes (such as record separators or otherdelimiters) is “hidden” under a compression layer that must be removedbefore this information can be detected and used inside SPU 500.

[0531] Random Number Generator 542

[0532] Optional random number generator 542 may provide specializedhardware circuitry for generating random values (e.g., from inherentlyunpredictable physical processes such as quantum noise). Such randomvalues are particularly useful for constructing encryption keys orunique identifiers, and for initializing the generation of pseudo-randomsequences. Random number generator 542 may produce values of anyconvenient length, including as small as a single bit per use. A randomnumber of arbitrary size may be constructed by concatenating valuesproduced by random number generator 542. A cryptographically strongpseudo-random sequence may be generated from a random key and seedgenerated with random number generator 542 and repeated encryptioneither with the encrypt/decrypt engine 522 or cryptographic algorithmsin SPU 500. Such sequences may be used, for example, in private headersto frustrate efforts to determine an encryption key throughcryptoanalysis.

[0533] Arithmetic Accelerator 544

[0534] An optional arithmetic accelerator 544 may be provided within anSPU 500 in the form of hardware circuitry that can rapidly performmathematical calculations such as multiplication and exponentiationinvolving large numbers. These calculations can, for example, berequested by microprocessor 520 or encrypt/decrypt engine 522, to assistin the computations required for certain asymmetricencryption/decryption operations. Such arithmetic accelerators arewell-known to those skilled in the art. In some implementations, aseparate arithmetic accelerator 544 may be omitted and any necessarycalculations may be performed by microprocessor 520 under softwarecontrol.

[0535] DMA Controller 526

[0536] DMA controller 526 controls information transfers overaddress/data bus 536 without requiring microprocessor 520 to processeach individual data transfer. Typically, microprocessor 520 may writeto DMA controller 526 target and destination addresses and the number ofbytes to transfer, and DMA controller 526 may then automaticallytransfer a block of data between components of SPU 500 (e.g., from ROM532 to RAM 534, between encrypt/decrypt engine 522 and RAM 534, betweenbus interface unit 530 and RAM 534, etc.). DMA controller 526 may havemultiple channels to handle multiple transfers simultaneously. In someimplementations, a separate DMA controller 526 may be omitted, and anynecessary data movements may be performed by microprocessor 520 undersoftware control.

[0537] Bus Interface Unit (BIU) 530

[0538] Bus interface unit (BIU) 530 communicates information between SPU500 and the outside world across the security barrier 502. BIU 530 shownin FIG. 9 plus appropriate driver software may comprise the “appliancelink” 510 shown in FIG. 6. Bus interface unit 530 may be modelled aftera USART or PCI bus interface in the preferred embodiment. In thisexample, BIU 530 connects SPU 500 to electronic appliance system bus 653shown in FIG. 8. BIU 530 is designed to prevent unauthorized access tointernal components within SPU 500 and their contents. It does this byonly allowing signals associated with an SPU 500 to be processed bycontrol programs running on microprocessor 520 and not supporting directaccess to the internal elements of an SPU 500.

[0539] Memory Management Unit 540

[0540] Memory Management Unit (MMU) 540, if present, provides hardwaresupport for memory management and virtual memory management functions.It may also provide heightened security by enforcing hardwarecompartmentalization of the secure execution space (e.g., to prevent aless trusted task from modifying a more trusted task). More details areprovided below in connection with a discussion of the architecture of aSecure Processing Environment (“SPE”) 503 supported by SPU 500.

[0541] MMU 540 may also provide hardware-level support functions relatedto memory management such as, for example, address mapping.

[0542] SPU Memory Architecture

[0543] In the preferred embodiment, SPU 500 uses three general kinds ofmemory:

[0544] (1) internal ROM 532;

[0545] (2) internal RAM 534; and

[0546] (3) external memory (typically RAM and/or disk supplied by a hostelectronic appliance).

[0547] The internal ROM 532 and RAM 534 within SPU 500 provide a secureoperating environment and execution space. Because of cost limitations,chip fabrication size, complexity and other limitations, it may not bepossible to provide sufficient memory within SPU 500 to store allinformation that an SPU needs to process in a secure manner. Due to thepractical limits on the amount of ROM 532 and RAM 534 that may beincluded within SPU 500, SPU 500 may store information in memoryexternal to it, and move this information into and out of its secureinternal memory space on an as needed basis. In these cases, secureprocessing steps performed by an SPU typically must be segmented intosmall, securely packaged elements that may be “paged in” and “paged out”of the limited available internal memory space. Memory external to anSPU 500 may not be secure. Since the external memory may not be secure,SPU 500 may encrypt and cryptographically seal code and otherinformation before storing it in external memory. Similarly, SPU 500must typically decrypt code and other information obtained from externalmemory in encrypted form before processing (e.g., executing) based onit. In the preferred embodiment, there are two general approaches usedto address potential memory limitations in a SPU 500. In the first case,the small, securely packaged elements represent information contained insecure database 610. In the second case, such elements may representprotected (e.g., encrypted) virtual memory pages. Although virtualmemory pages may correspond to information elements stored in securedatabase 610, this is not required in this example of a SPU memoryarchitecture.

[0548] The following is a more detailed discussion of each of thesethree SPU memory resources.

[0549] SPU Internal ROM

[0550] SPU 500 read only memory (ROM) 532 or comparable purpose deviceprovides secure internal non-volatile storage for certain programs andother information. For example, ROM 532 may store “kernel” programs suchas SPU control firmware 508 and, if desired, encryption key informationand certain fundamental “load modules.” The “kernel” programs, loadmodule information, and encryption key information enable the control ofcertain basic functions of the SPU 500. Those components that are atleast in part dependent on device configuration (e.g., POST, memoryallocation, and a dispatcher) may be loaded in ROM 532 along withadditional load modules that have been determined to be required forspecific installations or applications.

[0551] In the preferred embodiment, ROM 532 may comprise a combinationof a masked ROM 532 a and an EEPROM and/or equivalent “flash” memory 532b. EEPROM or flash memory 532 b is used to store items that need to beupdated and/or initialized, such as for example, certain encryptionkeys. An additional benefit of providing EEPROM and/or flash memory 532b is the ability to optimize any load modules and library functionspersistently stored within SPU 500 based on typical usage at a specificsite. Although these items could also be stored in NVRAM 534 b, EEPROMand/or flash memory 532 b may be more cost effective.

[0552] Masked ROM 532 a may cost less than flash and/or EEPROM 532 b,and can be used to store permanent portions of SPU software/firmware.Such permanent portions may include, for example, code that interfacesto hardware elements such as the RTC 528, encryption/decryption engine522, interrupt handlers, key generators, etc. Some of the operatingsystem, library calls, libraries, and many of the core services providedby SPU 500 may also be in masked ROM 532 a. In addition, some of themore commonly used executables are also good candidates for inclusion inmasked ROM 532 a. Items that need to be updated or that need todisappear when power is removed from SPU 500 should not be stored inmasked ROM 532 a.

[0553] Under some circumstances, RAM 534 a and/or NVRAM 534 b (NVRAM 534b may, for example, be constantly powered conventional RAM) may performat least part of the role of ROM 532.

[0554] SPU Internal RAM

[0555] SPU 500 general purpose RAM 534 provides, among other things,secure execution space for secure processes. In the preferredembodiment, RAM 534 is comprised of different types of RAM such as acombination of high-speed RAM 534 a and an NVRAM (“non-volatile RAM”)534 b. RAM 534 a may be volatile, while NVRAM 534 b is preferablybattery backed or otherwise arranged so as to be non-volatile (i.e., itdoes not lose its contents when power is turned off).

[0556] High-speed RAM 534 a stores active code to be executed andassociated data structures.

[0557] NVRAM 534 b preferably contains certain keys and summary valuesthat are preloaded as part of an initialization process in which SPU 500communicates with a VDE administrator, and may also store changeable orchanging information associated with the operation of SPU 500. Forsecurity reasons, certain highly sensitive information (e.g., certainload modules and certain encryption key related information such asinternally generated private keys) needs to be loaded into or generatedinternally by SPU 500 from time to time but, once loaded or generatedinternally, should never leave the SPU. In this preferred embodiment,the SPU 500 non-volatile random access memory (NVRAM) 534 b may be usedfor securely storing such highly sensitive information. NVRAM 534 b isalso used by SPU 500 to store data that may change frequently but whichpreferably should not be lost in a power down or power fail mode.

[0558] NVRAM 534 b is preferably a flash memory array, but may inaddition or alternatively be electrically erasable programmable readonly memory (EEPROM), static RAM (SRAM), bubble memory, threedimensional holographic or other electro-optical memory, or the like, orany other writable (e.g., randomly accessible) non-volatile memory ofsufficient speed and cost-effectiveness.

[0559] SPU External Memory

[0560] The SPU 500 can store certain information on memory devicesexternal to the SPU. If available, electronic appliance 600 memory canalso be used to support any device external portions of SPU 500software. Certain advantages may be gained by allowing the SPU 500 touse external memory. As one example, memory internal to SPU 500 may bereduced in size by using non-volatile read/write memory in the hostelectronic appliance 600 such as a non-volatile portion of RAM 656and/or ROM 658.

[0561] Such external memory may be used to store SPU programs, dataand/or other information. For example, a VDE control program may be, atleast in part, loaded into the memory and communicated to and decryptedwithin SPU 500 prior to execution. Such control programs may bere-encrypted and communicated back to external memory where they may bestored for later execution by SPU 500. “Kernel” programs and/or some orall of the non-kernel “load modules” may be stored by SPU 500 in memoryexternal to it. Since a secure database 610 may be relatively large, SPU500 can store some or all of secure database 610 in external memory andcall portions into the SPU 500 as needed.

[0562] As mentioned above, memory external to SPU 500 may not be secure.Therefore, when security is required, SPU 500 must encrypt secureinformation before writing it to external memory, and decrypt secureinformation read from external memory before using it. Inasmuch as theencryption layer relies on secure processes and information (e.g.,encryption algorithms and keys) present within SPU 500, the encryptionlayer effectively “extends” the SPU security barrier 502 to protectinformation the SPU 500 stores in memory external to it.

[0563] SPU 500 can use a wide variety of different types of externalmemory. For example, external memory may comprise electronic appliancesecondary storage 652 such as a disk; external EEPROM or flash memory658; and/or external RAM 656. External RAM 656 may comprise an externalnonvolatile (e.g. constantly powered) RAM and/or cache RAM.

[0564] Using external RAM local to SPU 500 can significantly improveaccess times to information stored externally to an SPU. For example,external RAM may be used:

[0565] a to buffer memory image pages and data structures prior to theirstorage in flash memory or on an external hard disk (assuming transferto flash or hard disk can occur in significant power or system failurecases);

[0566] provide encryption and decryption buffers for data being releasedfrom VDE objects 300.

[0567] to cache “swap blocks” and VDE data structures currently in useas an aspect of providing a secure virtual memory environment for SPU500.

[0568] to cache other information in order to, for example, reducefrequency of access by an SPU to secondary storage 652 and/or for otherreasons.

[0569] Dual ported external RAM can be particularly effective inimproving SPU 500 performance, since it can decrease the data movementoverhead of the SPU bus interface unit 530 and SPU microprocessor 520.

[0570] Using external flash memory local to SPU 500 can be used tosignificantly improve access times to virtually all data structures.Since most available flash storage devices have limited write lifetimes,flash storage needs to take into account the number of writes that willoccur during the lifetime of the flash memory. Hence, flash storage offrequently written temporary items is not recommended. If external RAMis non-volatile, then transfer to flash (or hard disk) may not benecessary.

[0571] External memory used by SPU 500 may include two categories:

[0572] external memory dedicated to SPU 500, and

[0573] memory shared with electronic appliance 600.

[0574] For some VDE implementations, sharing memory (e.g., electronicappliance RAM 656, ROM 658 and/or secondary storage 652) with CPU 654 orother elements of an electronic appliance 600 may be the most costeffective way to store VDE secure database management files 610 andinformation that needs to be stored external to SPU 500. A host systemhard disk secondary memory 652 used for general purpose file storagecan, for example, also be used to store VDE management files 610. SPU500 may be given exclusive access to the external memory (e.g., over alocal bus high speed connection provided by BIU 530). Both dedicated andshared external memory may be provided.

[0575] SPU Integrated within CPU

[0576] As discussed above, it may be desirable to integrate CPU 654 andSPU 500 into the same integrated circuit and/or device. SPU 500 shown inFIG. 9 includes a microprocessor 520 that may be similar or identical toa standard microprocessor available off-the-shelf from a variety ofmanufacturers. Similarly, the SPU DMA controller 526 and certain othermicroprocessor support circuitry may be standard implementationsavailable in off-the-shelf microprocessor and/or microcomputer chips.Since many of the general control and processing requirements providedby SPU 500 in the preferred embodiment can be satisfied using certaingeneric CPU and/or microcontroller components, it may be desirable tointegrate SPU VDE functionality into a standard generic CPU ormicrocontroller chip. Such an integrated solution can result in a verycost-effective “dual mode” component that is capable of performing allof the generic processing of a standard CPU as well as the secureprocessing of an SPU. Many of the control logic functions performed bythe preferred embodiment SPU can be performed by generic CPU and/ormicro-controller logic so that at least a portion of the control logicdoes not have to be duplicated. Additional cost savings (e.g., in termsof reducing manufacturing costs, inventory costs and printed circuitboard real estate requirements) may also be obtained by not requiring anadditional, separate physical SPU 500 device or package. FIG. 9A showsone example architecture of a combination CPU/SPU 2650. CPU/SPU 2650 mayinclude a standard microprocessor or microcontroller 2652, a standardbus interface unit (BIU) 2656, and a standard (optional) DMA controller2654, as well as various other standard I/O controllers, computationcircuitry, etc. as may be found in a typical off-the-shelfmicroprocessor/microcontroller. Real time clock 528 may be added to thestandard architecture to give the CPU/SPU 2650 access to the real timeclock functions as discussed above in connection with FIG. 9. Real-timeclock 528 must be protected from tampering in order to be secure. Suchprotections may include internal or external backup power, an indicationthat its power (and thus its operation) has been interrupted, and/or anindication that the external clock signal(s) from which it derives itstiming have been interfered with (e.g., sped up, slowed down).Similarly, an encrypt/decrypt engine 522, pattern matching engine 524,compression/decompression engine 546 and/or arithmetic accelerator 544may be added if desired to provide greater efficiencies, or thefunctions performed by these components could be provided instead bysoftware executing on microprocessor 2652. An optional memory managementunit 540 may also be provided if desired. A true random number generator542 may be provided also if desired. Connections shown between modeinterface switch 2658 and other components can carry both data andcontrol information, specifically control information that determineswhat security-relevant aspects of the other components are available foraccess and/or manipulation.

[0577] In addition, secure ROM 532 and/or secure RAM 534 may be providedwithin CPU/SPU 2650 along with a “mode interface switch” 2658 a, 2658 b.Mode interface switch 2658 selectively provides microprocessor 2652 withaccess to secure memory 532, 534 and other secure components (blocks522, 546, 524, 542, 544, 528) depending upon the “mode” CPU/SPU 2650 isoperating in. CPU/SPU 2650 in this example may operate in two differentmodes:

[0578] an “SPU” mode, or

[0579] a “normal” mode.

[0580] In the “normal” mode, CPU/SPU 2650 operates substantiallyidentically to a standard off-the-shelf CPU while also protecting thesecurity of the content, state, and operations of security-relevantcomponents included in CPU/SPU 2650. Such security-relevant componentsmay include the secure memories 532, 534; the encrypt/decrypt engine522, the optional pattern-matching engine 524, random number generator542, arithmetic accelerator 544, the SPU-not-initialized flag 2671, thesecure mode interface switch 2658, the real-time clock 528, the DMAcontroller 2654, the MMU 540, compress/decompress block 546, and/or anyother components that may affect security of the operation of theCPU/SPU in “SPU” mode.

[0581] In this example, CPU/SPU 2650 operating in the “normal” modecontrols mode interface switch 2658 to effectively “disconnect” (i.e.,block unsecure access to) the security-relevant components, or to thesecurity-relevant aspects of the operations of such components as have afunction for both “normal” and “SPU” mode. In the “normal” mode, forexample, microprocessor 2652 could access information from standardregisters or other internal RAM and/or ROM (not shown), executeinstructions in a “normal” way, and perform any other tasks as areprovided within a standard CPU—but could not access or compromise thecontents of secure memory 532, 534 or access blocks 522, 524, 542, 544,546. In this example “normal” mode, mode interface switch 2658 wouldeffectively prevent any access (e.g., both read and write access) tosecure memory 532, 534 so as to prevent the information stored withinthat secure memory from being compromised.

[0582] When CPU/SPU 2650 operates in the “SPU” mode, mode interfaceswitch 2658 allows microprocessor 2652 to access secure memory 532, 534,and to control security-relevant aspects of other components in theCPU/SPU. The “SPU” mode in this example requires all instructionsexecuted by microprocessor 2652 to be fetched from secure memory 532,534—preventing execution based on “mixed” secure and non-secureinstructions. In the “SPU” mode, mode interface switch 2658 may, in oneexample embodiment, disconnect or otherwise block external accessescarried over bus 652 from outside CPU/SPU 2650 (e.g., DMA accesses,cache coherency control accesses) to ensure that the microprocessor 2652is controlled entirely by instructions carried within or derived fromthe secure memory 532, 534. Mode interface switch 2658 may alsodisconnect or otherwise block access by microprocessor 2652 to someexternal memory and/or other functions carried over bus 652. Modeinterface switch 2658 in this example prevents other CPUoperations/instructions from exposing the contents of secure memory 532,534.

[0583] In the example shown in FIG. 9A, the mode control of modeinterface switch 2658 is based on a “mode” control signal provided bymicroprocessor 2652. In this example, microprocessor 2652 may beslightly modified so it can execute two “new” instructions:

[0584] “enable ‘SPU’ mode” instruction, and

[0585] “disable ‘SPU’ mode” instruction.

[0586] When microprocessor 2652 executes the “enable ‘SPU’ mode”instruction, it sends an appropriate “mode” control signal to modeinterface switch 2658 to “switch” the interface switch into the “SPU”mode of operation. When microprocessor 2652 executes the “disable ‘SPU’mode” instruction, it sends an appropriate “mode” control signal to modeinterface switch 2658 to disable the “SPU” mode of operation.

[0587] When CPU/SPU 2650 begins operating in the “SPU” mode (based onmicroprocessor 2652 executing the “enable “SPU” mode” instruction), modeinterface switch 2658 forces microprocessor 2652 to begin fetchinginstructions from secure memory 532, 534 (e.g., beginning at some fixedaddress) in one example. When CPU/SPU 2650 begins operating in thisexample “SPU” mode, mode interface switch 2658 may force microprocessor2652 to load its registers from some fixed address in secure memory 532,534 and may begin execution based on such register content. Onceoperating in the “SPU” mode, microprocessor 2652 may provideencryption/decryption and other control capabilities based upon the codeand other content of secure memory 532, 534 needed to provide the VDEfunctionality of SPU 500 described above. For example, microprocessor2652 operating under control of information within secure memory 532,534 may read encrypted information from bus 652 via bus interface unit2656, write decrypted information to the bus interface unit, and meterand limit decryption of such information based on values stored in thesecure memory.

[0588] At the end of secure processing, execution by microprocessor 2652of the “disable SPU mode” instruction may cause the contents of allregisters and other temporary storage locations used by microprocessor2652 that are not within secure memory 532, 534 to be destroyed orcopied into secure memory 532, 534 before “opening” mode interfaceswitch 2658. Once mode interface switch 2658 is “open,” themicroprocessor 2652 no longer has access to secure memory 532, 534 orthe information it contained, or to control or modify the state of anyother security-relevant components or functions contained within CPU/SPU2650 to which access is controlled by mode interface switch 2658.

[0589] Whenever CPU/SPU 2650 enters or leaves the “SPU” mode, thetransition is performed in such a way that no information contained inthe secure memory 532, 534 or derived from it (e.g., stored in registersor a cache memory associated with microprocessor 2652) while in the“SPU” mode can be exposed by microprocessor 2652 operations that occurin the “normal” mode. This may be accomplished either by hardwaremechanisms that protect against such exposure, software instructionsexecuted in “SPU” mode that clear, reinitialize, and otherwise resetduring such transitions, or a combination of both.

[0590] In some example implementations, interrupts may be enabled whileCPU/SPU 2650 is operating in the “SPU” mode similarly interrupts andreturns from interrupts while in the “SPU” mode may allow transitionsfrom “SPU” mode to “normal” mode and back to “SPU” mode without exposingthe content of secure memory 532, 534 or the content of registers orother memory associated with microprocessor 2652 that may containinformation derived from secure mode operation.

[0591] In some example implementations, there may be CPU/SPU activitiessuch as DMA transfers between external memory and/or devices and securememory 532, 534 that are initiated by microprocessor 2652 but involveautonomous activity by DMA controller 2654 and, optionally,encrypt/decrypt engine 522 and/or compress/decompress engine 546. Insuch implementations, mode interface switch 2658 and its associatedcontrol signals may be configured to permit such pending activities(e.g. DMA transfers) to continue to completion even after CPU/SPU 2650leaves “SPU” mode, provided that upon completion, all required clearing,reinitialization, and/or reset activities occur, and provided that noaccess or interference is permitted with the pending activities exceptwhen CPU/SPU 2650 is operating in “SPU” mode.

[0592] In an additional example embodiment, encryption/decryption logicmay be connected between microprocessor 2652 and secure memory 532, 354.This additional encryption/decryption logic may be connected “inparallel” to mode interface switch 2658. The additionalencryption/decryption logic may allow certain accesses by microprocessor2652 to the secure memory 532, 534 when CPU/SPU 2650 is operating in the“normal” mode. In this alternate embodiment, reads from secure memory532, 534 when CPU/SPU 2650 is operating in the “normal” modeautomatically result in the read information being encrypted before itis delivered to microprocessor 2652 (and similarly, and writes to thesecure memory may result in the written information being decryptedbefore it is deposited into the secure memory). This alternativeembodiment may permit access to secure memory 532, 534 (which may inthis example store the information in “clear” form) by microprocessor2652 when CPU/SPU 2650 is operating in the “non-secure normal” mode, butonly reveals the secure memory contents to microprocessor 2652 inunencrypted form when the CPU/SPU is operating in the “SPU” mode. Suchaccess may also be protected by cryptographic authentication techniques(e.g., message authentication codes) to prevent modification or replayattacks that modify encrypted data stored in secure memory 532, 534.Such protection may be performed utilizing either or both of softwareand/or hardware cryptographic techniques.

[0593] All of the components shown in FIG. 9A may be disposed within asingle integrated circuit package. Alternatively, mode interface switch2658 and secure memory 532, 534, and other security-relevant componentsmight be placed within an integrated circuit chip package and/or otherpackage separate from the rest of CPU/SPU 2650. In this two-packageversion, a private bus could be used to connect microprocessor 2652 tothe mode interface switch 2658 and associated secure memory 532, 534. Tomaintain security in such multi-package versions, it may be necessary toenclose all the packages and their interconnections in an externalphysical tamper-resistant barrier.

[0594] Initialization of Integrated CPU/SPU

[0595] Instructions and/or data may need to be loaded into CPU/SPU 2650before it can operate effectively as an SPU 500. This may occur duringthe manufacture of CPU/SPU 2650 or subsequently at a CPU/SPUinitialization facility. Security of such initialization may depend onphysical control of access to the CPU/SPU component(s), on cryptographicmeans, or on some combination of both. Secure initialization may beperformed in plural steps under the control of different parties, suchthat an initialization step to be performed by party B is preconditionedon successful performance of a step by party A. Different initializationsteps may be protected using different security techniques (e.g.physical access, cryptography).

[0596] In this example, switch 2658 may expose an external controlsignal 2670 that requests operation in “SPU” mode rather than “normal”mode after a power-on reset. This signal would be combined (e.g., by alogical AND 2672) with a non-volatile storage element 2671 internal toCPU/SPU 2650. If both of these signals are asserted, AND gate 2672 wouldcause CPU/SPU 2650 to begin operating in SPU mode, either executingexisting instructions from an address in SPU memory 532, executinginstructions from main memory 2665 or otherwise external to the CPU/SPU.The instructions thus executed would permit arbitrary initialization andother functions to be performed in “SPU” mode without necessarilyrequiring any instructions to be previously resident in the SPU memory532.

[0597] Once initialized, the SPU would, under control of itsinitialization program, indicate to switch 2658 that the flag 2671 is tobe cleared. Clearing flag 2671 would permanently disable thisinitialization capability because no mechanism would be provided to setflag 2671 back to its initial value. If flag 2671 is clear, or controlsignal 2670 is not asserted, CPU/SPU 2650 would behave precisely as doesmicroprocessor 2652 with respect to power-on reset and other externalconditions. Under such conditions, only execution of the “enable SPUmode” instruction or otherwise requesting SPU mode under program controlwould cause “SPU” mode to be entered.

[0598] Additionally, a mechanism could be provided to permitmicroprocessor 2652 and/or control signal 2672 to reinitialize the flag2671. Such reinitialization would be performed in a manner that clearedsecure memory 532, 534 of any security-relevant information andreinitialized the state of all security-relevant components. Thisreinitialization mechanism would permit CPU/SPU 2650 to be initializedseveral times, facilitating testing and/or refuse for differentapplications, while protecting all security-relevant aspects of itsoperation.

[0599] In the preferred embodiment, CPU/SPU 2650 would, when SPU modehas not yet been established, begin operating in SPU mode by fetchinginstructions from secure non-volatile memory 532, thereby ensuring aconsistent initialization sequence and preventing SPU dependence on anyinformation held outside CPU/SPU 2650. This approach permits secretinitialization information (e.g., keys for validating digital signatureson additional information to be loaded into secure memory 532, 534) tobe held internally to CPU/SPU 2650 so that it is never exposed tooutside access. Such information could even be supplied by a hardware“mask” used in the semiconductor fabrication process.

[0600] CPU/SPU Integrated with Unmodified Microprocessor

[0601]FIG. 9B shows an additional example embodiment, in which acompletely standard microprocessor 2652 integrated circuit chip could betransformed into a CPU/SPU 2650 by adding an SPU chip 2660 that mediatesaccess to external I/O devices and memory. In such an embodiment, themicroprocessor 2652 would be connected to the SPU chip 2660 by a privatememory bus 2661, and all three such components would be contained withinhardware tamper-resistant barrier 502.

[0602] In this embodiment, SPU chip 2660 may have the same securecomponents as in FIG. 9, i.e., it may have a ROM/EEPROM 532, a RAM 532,an RTC 528, an (optional) encryption/decryption engine 522, an(optional) random number generator (RNG) 542, an (optional) arithmeticaccelerator 544, and a (optional) compression/decompression engine 546,and a (optional) pattern matching circuit 524. Microprocessor 520 isomitted from SPU chip 2660 since the standard microprocessor 2650performs the processing functions instead. In addition, SPU chip 2660may include a flag 2671 and AND gate logic 2672 for the initializationpurposes discussed above.

[0603] In addition, SPU chip 2660 includes an enhanced switch 2663 thatprovides the same overall (bus enhanced) functionality performed by theswitch 2658 in the FIG. 9A embodiment.

[0604] Enhanced switch 2663 would perform the functions of a busrepeater, mediator and interpreter. For example, enhanced switch 2663may act as a bus repeater that enables microprocessor 2652's memoryaccesses made over internal memory bus 2661 to be reflected to externalmemory bus 2664 and performed on main memory 2665. Enhanced switch 2663may also act as a bus repeater similarly for internal I/O bus 2662 toexternal I/O bus 2665 in the event that microprocessor 2652 performs I/Ooperations distinctly from memory operations. Enhanced switch 2663 mayalso perform the function of a mediator for microprocessor controlfunctions 2666 (e.g., non-maskable interrupt, reset) with respect toexternally requested control functions 2667. Enhanced switch 2663 mayalso provide mediation for access to SPU-protected resources such as ROM532, RAM 534, encrypt/decrypt engine 522 (if present), random numbergenerator 542 (if present), arithmetic accelerator 544 (if present),pattern matching engine 524 (if present), and real-time clock 528 (ifpresent). Enhanced switch 2663 may also act as an interpreter of controlsignals received from microprocessor 2652 indicating entry to, exitfrom, and control of SPU mode.

[0605] Switch 2663 in this example recognizes a specific indication(e.g., an instruction fetch access to a designated address in the securememory 532) as the equivalent to the “enable ‘SPU’ mode” instruction.Upon recognizing such an indication, it may isolate the CPU/SPU 2650from external buses and interfaces 2664, 2665, and 2667 such that anyexternal activity, such as DMA cycles, would be “held” until the switch2663 permits access again. After this, switch 2663 permits a singleaccess to a specific location in secure memory 532 to complete.

[0606] The single instruction fetched from the designated locationperforms a control operation (a cache flush, for example), that can onlybe performed in microprocessor 2652's most privileged operating mode,and that has an effect visible to switch 2663. Switch 2663 awaits theoccurrence of this event, and if it does not occur within the expectednumber of cycles, does not enter “SPU” mode.

[0607] Occurrence of the control operation demonstrates thatmicroprocessor 2652 is executing in its most privileged “normal” modeand therefore can be trusted to execute successfully the “enter ‘SPU’mode” sequence of instructions stored in secure memory 532. Ifmicroprocessor 2652 were not executing in its most privileged mode,there would be no assurance that those instructions would executesuccessfully. Because switch 2663 isolates microprocessor 2652 fromexternal signals (e.g., interrupts) until “SPU” mode is successfullyinitialized, the entry instructions can be guaranteed to completesuccessfully.

[0608] Following the initial instruction, switch 2663 can enter “partialSPU mode,” in which a restricted area of ROM 532 and RAM 534 may beaccessible. Subsequent instructions in secure memory 532 may then beexecuted by microprocessor 2652 to place it into a known state such thatit can perform SPU functions—saving any previous state in the restrictedarea of RAM 534 that is accessible. After the known state isestablished, an instruction may be executed to deliver a furtherindication (e.g., a reference to another designated memory location) toswitch 2663, which would enter “SPU” mode. If this further indication isnot received within the expected interval, switch 2663 will not enter“SPU” mode. Once in “SPU” mode, switch 2663 permits access to all of ROM532, RAM 534, and other devices in SPU chip 2660.

[0609] The instructions executed during “partial SPU” mode must becarefully selected to ensure that no similar combination of instructionsand processor state could result in a control transfer out of theprotected SPU code in ROM 532 or RAM 534. For example, internaldebugging features of microprocessor 2652 must be disabled to ensurethat a malicious program could not set up a breakpoint later withinprotected SPU code and receive control. Similarly, all addresstranslation must be disabled or reinitialized to ensure that previouslycreated MMU data structures would not permit SPU memory accesses to becompromised. The requirement that the instructions for “partial SPUmode” run in the microprocessor 2652's most privileged mode is necessaryto ensure that all its processor control functions can be effectivelydisabled.

[0610] The switch 2663 provides additional protection against tamperingby ensuring that the expected control signals occur after an appropriatenumber of clock cycles. Because the “partial SPU” initializationsequence is entirely deterministic, it is not feasible for malicioussoftware to interfere with it and still retain the same timingcharacteristics, even if malicious software is running in microprocessor2652's most privileged mode.

[0611] Once in “SPU” mode, switch 2663 may respond to additionalindications or signals generated by microprocessor 2652 (e.g.,references to specific memory addresses) controlling features of SPUmode. These might include enabling access to external buses 2664 and2665 so that SPU-protected code could reference external memory ordevices. Any attempts by components outside CPU/SPU 2650 to performoperations (e.g., accesses to memory, interrupts, or other controlfunctions) may be prevented by switch 2663 unless they had beenexplicitly enabled by instructions executed after “SPU” mode is entered.To leave SPU mode and return to normal operation, the instructionsexecuting in “SPU” mode may provide a specific indication to switch 2663(e.g., a transfer to a designated memory address). This indication maybe recognized by switch 2663 as indicating a return to “normal mode,”and it may again restrict access to ROM 532, RAM 534, and all otherdevices within SPU chip 2660, while re-enabling external buses andcontrol lines 2664, 2665, and 2667. The instructions executedsubsequently may restore the CPU state to that which was saved on entryto SPU mode, so that microprocessor 2652 may continue to performfunctions in progress when the SPU was invoked.

[0612] In an alternate embodiment, the entry into SPU mode may beconditioned on an indication recognized by switch 2663, but the switchmay then use a hardware mechanism (e.g., the processor's RESET signal)to reinitialize microprocessor 2562. In such an embodiment, switch 2663may not implement partial SPU mode, but may instead enter SPU modedirectly and ensure that the address from which instructions would befetched by microprocessor 2652 (specific to microprocessor 2652'sarchitecture) results in accesses to appropriate locations in the SPUmemory 532. This could reduce the complexity of the SPU mode entrymechanisms in switch 2663, but could incur an additional processing costfrom using a different reinitialization mechanism for microprocessor2652.

[0613] SPU chip 2660 may be customized to operate in conjunction with aparticular commercial microprocessor. In this example, the SPU may becustomized to contain at least the specialized “enter SPU mode”instruction sequences to reinitialize the processor's state and, torecognize special indications for SPU control operations. SPU chip 2660may also be made electrically compatible with microprocessor 2652'sexternal bus interfaces. This compatibility would permit CPU/SPU 2650 tobe substituted for microprocessor 2652 without change either to softwareor hardware elsewhere in a computer system.

[0614] In other alternate embodiments, the functions described above forSPU chip 2600, microprocessor 2652, and internal buses 2661, 2662, and2666 could all be combined within a single integrated circuit package,and/or on a single silicon die. This could reduce packaging complexityand/or simplify establishment of the hardware tamper-resistant barrier502.

[0615] The hardware configuration of an example of electronic appliance600 has been described above. The following section describes an exampleof the software architecture of electronic appliance 600 provided by thepreferred embodiment, including the structure and operation of preferredembodiment “Rights Operating System” (“ROS”) 602.

[0616] Rights Operating System 602

[0617] Rights Operating System (“ROS”) 602 in the preferred embodimentis a compact, secure, event-driven, services-based, “component”oriented, distributed multiprocessing operating system environment thatintegrates VDE information security control information, components andprotocols with traditional operating system concepts. Like traditionaloperating systems, ROS 602 provided by the preferred embodiment is apiece of software that manages hardware resources of a computer systemand extends management functions to input and/or output devices,including communications devices. Also like traditional operatingsystems, preferred embodiment ROS 602 provides a coherent set of basicfunctions and abstraction layers for hiding the differences between, andmany of the detailed complexities of, particular hardwareimplementations. In addition to these characteristics found in many ormost operating systems, ROS 602 provides secure VDE transactionmanagement and other advantageous features not found in other operatingsystems. The following is a non-exhaustive list of some of theadvantageous features provided by ROS 602 in the preferred embodiment:

[0618] Standardized Interface Provides Coherent Set of Basic Functions

[0619] simplifies programming

[0620] the same application can run on many different platforms

[0621] Event Driven

[0622] eases functional decomposition

[0623] extendible

[0624] accommodates state transition and/or process oriented events

[0625] simplifies task management

[0626] simplifies inter-process communications

[0627] Services Based

[0628] allows simplified and transparent scalability

[0629] simplifies multiprocessor support

[0630] hides machine dependencies

[0631] eases network management and support

[0632] Component Based Architecture

[0633] processing based on independently deliverable secure components

[0634] component model of processing control allows different sequentialsteps that are reconfigurable based on requirements

[0635] components can be added, deleted or modified (subject topermissioning)

[0636] full control information over pre-defined and user-definedapplication events

[0637] events can be individually controlled with independentexecutables

[0638] Secure

[0639] secure communications

[0640] secure control functions

[0641] secure virtual memory management

[0642] information control structures protected from exposure

[0643] data elements are validated, correlated and access controlled

[0644] components are encrypted and validated independently

[0645] components are tightly correlated to prevent unauthorized use ofelements

[0646] control structures and secured executables are validated prior touse to protect against tampering

[0647] integrates security considerations at the I/O level

[0648] provides on-the-fly decryption of information at release time

[0649] enables a secure commercial transaction network

[0650] flexible key management features

[0651] Scalaeble

[0652] highly scalaeble across many different platforms

[0653] supports concurrent processing in a multiprocessor environment

[0654] supports multiple cooperating processors

[0655] any number of host or security processors can be supported

[0656] control structures and kernel are easily portable to various hostplatforms and to different processors within a target platform withoutrecompilation

[0657] supports remote processing

[0658] Remote Procedure Calls may be used for internal OS communications

[0659] Highly Integratable

[0660] can be highly integrated with host platforms as an additionaloperating system layer

[0661] permits non-secure storage of secured components and informationusing an OS layer “on top of” traditional OS platforms

[0662] can be seamlessly integrated with a host operating system toprovide a common usage paradigm for transaction management and contentaccess

[0663] integration may take many forms: operating system layers fordesktops (e.g. DOS, Windows, Macintosh); device drivers and operatingsystem interfaces for network services (e.g, Unix and Netware); anddedicated component drivers for “low end” set tops are a few of manyexamples

[0664] can be integrated in traditional and real time operating systems

[0665] Distributed

[0666] provides distribution of control information and reciprocalcontrol information and mechanisms

[0667] supports conditional execution of controlled processes within anyVDE node in a distributed, asynchronous arrangement

[0668] controlled delegation of rights in a distributed environment

[0669] supports chains of handling and control

[0670] management environment for distributed, occasionally connectedbut otherwise asynchronous networked database

[0671] real time and time independent data management

[0672] supports “agent” processes

[0673] Transparent

[0674] can be seamlessly integrated into existing operating systems

[0675] can support applications not specifically written to use it

[0676] Network Friendly

[0677] internal OS structures may use RPCs to distribute processing

[0678] subnets may seamlessly operate as a single node or independently

[0679] General Background Regarding Operating Systems

[0680] An “operating system” provides a control mechanism for organizingcomputer system resources that allows programmers to create applicationsfor computer systems more easily. An operating system does this byproviding commonly used functions, and by helping to ensurecompatibility between different computer hardware and architectures(which may, for example, be manufactured by different vendors).Operating systems also enable computer “peripheral device” manufacturersto far more easily supply compatible equipment to computer manufacturersand users.

[0681] Computer systems are usually made up of several differenthardware components. These hardware components include, for example:

[0682] a central processing unit (CPU for executing instructions:

[0683] an array of main memory cells (e.g., “RAM” or “ROM”) for storinginstructions for execution and data acted upon or parameterizing thoseinstructions; and

[0684] one or more secondary storage devices (e.g., hard disk drive,floppy disk drive, CD-ROM drive, tape reader, card reader, or “flash”memory) organized to reflect named elements (a “file system”) forstoring images of main memory cells.

[0685] Most Computer Systems also Include Input/Output Devices such asKeyboards, Mice, Video Systems, Printers, Scanners and communicationsdevices.

[0686] To organize the CPUs execution capabilities with available RAM,ROM and secondary storage devices, and to provide commonly usedfunctions for use by programmers, a piece of software called an“operating system” is usually included with the other components.Typically, this piece of software is designed to begin executing afterpower is applied to the computer system and hardware diagnostics arecompleted. Thereafter, all use of the CPU, main memory and secondarymemory devices is normally managed by this “operating system” software.Most computer operating systems also typically include a mechanism forextending their management functions to I/O and other peripheraldevices, including commonly used functions associated with thesedevices.

[0687] By managing the CPU, memory and peripheral devices through theoperating system, a coherent set of basic functions and abstractionlayers for hiding hardware details allows programmers to more easilycreate sophisticated applications. In addition, managing the computer'shardware resources with an operating system allows many differences indesign and equipment requirements between different manufacturers to behidden. Furthermore, applications can be more easily shared with othercomputer users who have the same operating system, with significantlyless work to support different manufacturers' base hardware andperipheral devices.

[0688] ROS 602 is an Operating System Providing Significant Advantages

[0689] ROS 602 is an “operating system.” It manages the resources ofelectronic appliance 600, and provides a commonly used set of functionsfor programmers writing applications 608 for the electronic appliance.ROS 602 in the preferred embodiment manages the hardware (e.g., CPU(s),memory(ies), secure RTC(s), and encrypt/decrypt engines) within SPU 500.ROS may also manage the hardware (e.g., CPU(s) and memory(ies)) withinone or more general purpose processors within electronic appliance 600.ROS 602 also manages other electronic appliance hardware resources, suchas peripheral devices attached to an electronic appliance. For example,referring to FIG. 7, ROS 602 may manage keyboard 612, display 614, modem618, disk drive 620, printer 622, scanner 624. ROS 602 may also managesecure database 610 and a storage device (e.g., “secondary storage” 652)used to store secure database 610.

[0690] ROS 602 supports multiple processors. ROS 602 in the preferredembodiment supports any number of local and/or remote processors.Supported processors may include at least two types: one or moreelectronic appliance processors 654, and/or one or more SPUs 500. A hostprocessor CPU 654 may provide storage, database, and communicationsservices. SPU 500 may provide cryptographic and secured processexecution services. Diverse control and execution structures supportedby ROS 602 may require that processing of control information occurwithin a controllable execution space—this controllable execution spacemay be provided by SPU 500. Additional host and/or SPU processors mayincrease efficiencies and/or capabilities. ROS 602 may access,coordinate and/or manage further processors remote to an electronicappliance 600 (e.g. via network or other communications link) to provideadditional processor resources and/or capabilities.

[0691] ROS 602 is services based, The ROS services provided using a hostprocessor 654 and/or a secure processor (SPU 500) are linked in thepreferred embodiment using a “Remote Procedure Call” (“RPC”) internalprocessing request structure. Cooperating processors may requestinterprocess services using a RPC mechanism, which is minimally timedependent and can be distributed over cooperating processors on anetwork of hosts. The multi-processor architecture provided by ROS 602is easily extensible to support any number of host or securityprocessors. This extensibility supports high levels of scalability.Services also allow functions to be implemented differently on differentequipment. For example, a small appliance that typically has low levelsof usage by one user may implement a database service using verydifferent techniques than a very large appliance with high levels ofusage by many users. This is another aspect of scalability.

[0692] ROS 602 provides a distributed processing environment. Forexample, it permits information and control structures to automatically,securely pass between sites as required to fulfill a user's requests.Communications between VDE nodes under the distributed processingfeatures of ROS 602 may include interprocess service requests asdiscussed above. ROS 602 supports conditional and/or state dependentexecution of controlled processors within any VDE node. The locationthat the process executes and the control structures used may be locallyresident, remotely accessible, or carried along by the process tosupport execution on a remote system.

[0693] ROS 602 provides distribution of control information, includingfor example the distribution of control structures required to permit“agents” to operate in remote environments. Thus, ROS 602 providesfacilities for passing execution and/or information control as part ofemerging requirements for “agent” processes.

[0694] If desired, ROS 602 may independently distribute controlinformation over very low bandwidth connections that may or may not be“real time” connections. ROS 602 provided by the preferred embodiment is“network friendly,” and can be implemented with any level of networkingprotocol. Some examples include e-mail and direct connection atapproximately “Layer 5” of the ISO model.

[0695] The ROS 602 distribution process (and the associated auditing ofdistributed information) is a controlled event that itself uses suchcontrol structures. This “reflective” distributed processing mechanismpermits ROS 602 to securely distribute rights and permissions in acontrolled manner, and effectively restrict the characteristics of useof information content. The controlled delegation of rights in adistributed environment and the secure processing techniques used by ROS602 to support this approach provide significant advantages.

[0696] Certain control mechanisms within ROS 602 are “reciprocal.”Reciprocal control mechanisms place one or more control components atone or more locations that interact with one or more components at thesame or other locations in a controlled way. For example, a usagecontrol associated with object content at a user's location may have areciprocal control at a distributor's location that governs distributionof the usage control, auditing of the usage control, and logic toprocess user requests associated with the usage control. A usage controlat a user's location (in addition to controlling one or more aspects ofusage) may prepare audits for a distributor and format requestsassociated with the usage control for processing by a distributor.Processes at either end of a reciprocal control may be furthercontrolled by other processes (e.g., a distributor may be limited by abudget for the number of usage control mechanisms they may produce).Reciprocal control mechanisms may extend over many sites and many levels(e.g., a creator to a distributor to a user) and may take anyrelationship into account (e.g., creator/distributor, distributor/user,user/user, user/creator, user/creator/distributor, etc.) Reciprocalcontrol mechanisms have many uses in VDE 100 in representingrelationships and agreements in a distributed environment.

[0697] ROS 602 is scalable. Many portions of ROS 602 control structuresand kernel(s) are easily portable to various host platforms withoutrecompilation. Any control structure may be distributed (orredistributed) if a granting authority permits this type of activity.The executable references within ROS 602 are portable within a targetplatform. Different instances of ROS 602 may execute the referencesusing different resources. For example, one instance of ROS 602 mayperform a task using an SPU 500, while another instance of ROS 602 mightperform the same task using a host processing environment running inprotected memory that is emulating an SPU in software. ROS 602 controlinformation is similarly portable; in many cases the event processingstructures may be passed between machines and host platforms as easilyas between cooperative processors in a single computer. Appliances withdifferent levels of usage and/or resources available for ROS 602functions may implement those functions in very different ways. Someservices may be omitted entirely if insufficient resources exist. Asdescribed elsewhere, ROS 602 “knows” what services are available, andhow to proceed based on any given event. Not all events may beprocessable if resources are missing or inadequate.

[0698] ROS 602 is component based. Much of the functionality provided byROS 602 in the preferred embodiment may be based on “components” thatcan be securely, independently deliverable, replaceable and capable ofbeing modified (e.g., under appropriately secure conditions andauthorizations). Moreover, the “components” may themselves be made ofindependently deliverable elements. ROS 602 may assemble these elementstogether (using a construct provided by the preferred embodiment calleda “channel”) at execution time. For example, a “load module” forexecution by SPU 500 may reference one or more “method cores,” methodparameters and other associated data structures that ROS 602 may collectand assemble together to perform a task such as billing or metering.Different users may have different combinations of elements, and some ofthe elements may be customizable by users with appropriateauthorization. This increases flexibility, allows elements to be reused,and has other advantages.

[0699] ROS 602 is highly secure. ROS 602 provides mechanisms to protectinformation control structures from exposure by end users and conduithosts. ROS 602 can protect information, VDE control structures andcontrol executables using strong encryption and validation mechanisms.These encryption and validation mechanisms are designed to make themhighly resistant to undetected tampering. ROS 602 encrypts informationstored on secondary storage device(s) 652 to inhibit tampering. ROS 602also separately encrypts and validates its various components. ROS 602correlates control and data structure components to prevent unauthorizeduse of elements. These features permit ROS 602 to independentlydistribute elements, and also allows integration of VDE functions 604with non-secure “other” OS functions 606.

[0700] ROS 602 provided by the preferred embodiment extends conventionalcapabilities such as, for example, Access Control List (ACL) structures,to user and process defined events, including state transitions. ROS 602may provide fill control information over pre-defined and user-definedapplication events. These control mechanisms include “go/no-go”permissions, and also include optional event-specific executables thatpermit complete flexibility in the processing and/or controlling ofevents. This structure permits events to be individually controlled sothat, for example, metering and budgeting may be provided usingindependent executables. For example, ROS 602 extends ACL structures tocontrol arbitrary granularity of information. Traditional operatingsystems provide static “go-no go” control mechanisms at a file orresource level; ROS 602 extends the control concept in a general wayfrom the largest to the smallest sub-element using a flexible controlstructure. ROS 602 can, for example, control the printing of a singleparagraph out of a document file.

[0701] ROS 602 provided by the preferred embodiment permits securemodification and update of control information governing each component.The control information may be provided in a template format such asmethod options to an end-user. An end-user may then customize the actualcontrol information used within guidelines provided by a distributor orcontent creator. Modification and update of existing control structuresis preferably also a controllable event subject to auditing and controlinformation.

[0702] ROS 602 provided by the preferred embodiment validates controlstructures and secured executables prior to use. This validationprovides assurance that control structures and executables have not beentampered with by end-users. The validation also permits ROS 602 tosecurely implement components that include fragments of files and otheroperating system structures. ROS 602 provided by the preferredembodiment integrates security considerations at the operating systemI/O level (which is below the access level), and provides “on-the-fly”decryption of information at release time. These features permitnon-secure storage of ROS 602 secured components and information usingan OS layer “on top of” traditional operating system platforms.

[0703] ROS 602 is highly integratable with host platforms as anadditional operating system layer. Thus, ROS 602 may be created by“adding on” to existing operating systems. This involves hooking VDE“add ons” to the host operating system at the device driver and networkinterface levels. Alternatively, ROS 602 may comprise a wholly newoperating system that integrates both VDE functions and other operatingsystem functions.

[0704] Indeed, there are at least three general approaches tointegrating VDE functions into a new operating system, potentially basedon an existing operating system, to create a Rights Operating System 602including:

[0705] (1) Redesign the operating system based on VDE transactionmanagement requirements:

[0706] (2) Compile VDE API functions into an existing operating systems;and

[0707] (3) Integrate a VDE Interpreter into an existing operatingsystem.

[0708] The first approach could be most effectively applied when a newoperating system is being designed, or if a significant upgrade to anexisting operating system is planned. The transaction management andsecurity requirements provided by the VDE functions could be added tothe design requirements list for the design of a new operating systemthat provides, in an optimally efficient manner, an integration of“traditional” operating system capabilities and VDE capabilities. Forexample, the engineers responsible for the design of the new version orinstance of an operating system would include the requirements of VDEmetering/transaction management in addition to other requirements (ifany) that they use to form their design approach, specifications, andactual implementations. This approach could lead to a “seamless”integration of VDE functions and capabilities by threadingmetering/transaction management functionality throughout the systemdesign and implementation.

[0709] The second approach would involve taking an existing set of API(Application Programmer Interface) functions, and incorporatingreferences in the operating system code to VDE function calls. This issimilar to the way that the current Windows operating system isintegrated with DOS, wherein DOS serves as both the launch point and asa significant portion of the kernel underpinning of the Windowsoperating system. This approach would be also provide a high degree of“seamless” integration (although not quite as “seamless” as the firstapproach). The benefits of this approach include the possibility thatthe incorporation of metering/transaction management functionality intothe new version or instance of an operating system may be accomplishedwith lower cost (by making use of the existing code embodied in an API,and also using the design implications of the API functional approach toinfluence the design of the elements into which the metering/transactionmanagement functionality is incorporated).

[0710] The third approach is distinct from the first two in that it doesnot incorporate VDE functionality associated with metering/transactionmanagement and data security directly into the operating system code,but instead adds a new generalized capability to the operating systemfor executing metering/transaction management functionality. In thiscase, an interpreter including metering/transaction management functionswould be integrated with other operating system code in a “stand alone”mode. This interpreter might take scripts or other inputs to determinewhat metering/transaction management functions should be performed, andin what order and under which circumstances or conditions they should beperformed.

[0711] Instead of (or in addition to) integrating VDE functionsinto/with an electronic appliance operating system, it would be possibleto provide certain VDE functionality available as an application runningon a conventional operating system.

[0712] ROS Software Architecture

[0713]FIG. 10 is a block diagram of one example of a softwarestructure/architecture for Rights Operating System (“ROS”) 602 providedby the preferred embodiment. In this example, ROS 602 includes anoperating system (“OS”) “core” 679, a user Application Program Interface(“API”) 682, a “redirector” 684, an “intercept” 692, a UserNotification/Exception Interface 686, and a file system 687. ROS 602 inthis example also includes one or more Host Event ProcessingEnvironments (“HPEs”) 655 and/or one or more Secure Event ProcessingEnvironments (“SPEs”) 503 (these environments may be genericallyreferred to as “Protected Processing Environments” 650).

[0714] HPE(s) 655 and SPE(s) 503 are self-contained computing andprocessing environments that may include their own operating systemkernel 688 including code and data processing resources. A givenelectronic appliance 600 may include any number of SPE(s) 503 and/or anynumber of HPE(s) 655. HPE(s) 655 and SPE(s) 503 may process informationin a secure way, and provide secure processing support for ROS 602. Forexample, they may each perform secure processing based on one or moreVDE component assemblies 690, and they may each offer secure processingservices to OS kernel 680.

[0715] In the preferred embodiment, SPE 503 is a secure processingenvironment provided at least in part by an SPU 500. Thus, SPU 500provides the hardware tamper-resistant barrier 503 surrounding SPE 503.SPE 503 provided by the preferred embodiment is preferably:

[0716] small and compact

[0717] loadable into resource constrained environments such as forexample minimally configured SPUs 500

[0718] dynamically updatable

[0719] extensible by authorized users

[0720] integratable into object or procedural environments

[0721] secure

[0722] In the preferred embodiment, HPE 655 is a secure processingenvironment supported by a processor other than an SPU, such as forexample an electronic appliance CPU 654 general-purpose microprocessoror other processing system or device. In the preferred embodiment, HPE655 may be considered to “emulate” an SPU 500 in the sense that it mayuse software to provide some or all of the processing resources providedin hardware and/or firmware by an SPU. HPE 655 in one preferredembodiment of the present invention is full-featured and fullycompatible with SPE 503—that is, HPE 655 can handle each and everyservice call SPE 503 can handle such that the SPE and the HPE are “plugcompatible” from an outside interface standpoint (with the exceptionthat the HPE may not provide as much security as the SPE).

[0723] HPEs 655 may be provided in two types: secure and not secure. Forexample, it may be desirable to provide non-secure versions of HPE 655to allow electronic appliance 600 to efficiently run non-sensitive VDEtasks using the full resources of a fast general purpose processor orcomputer. Such non-secure versions of HPE 655 may run under supervisionof an instance of ROS 602 that also includes an SPE 503. In this way,ROS 602 may run all secure processes within SPE 503, and only use HPE655 for processes that do not require security but that may require (orrun more efficiently) under potentially greater resources provided by ageneral purpose computer or processor supporting HPE 655. Non-secure andsecure HPE 655 may operate together with a secure SPE 503.

[0724] HPEs 655 may (as shown in FIG. 10) be provided with asoftware-based tamper resistant barrier 674 that makes them more secure.Such a software-based tamper resistant barrier 674 may be created bysoftware executing on general-purpose CPU 654. Such a “secure” HPE 655can be used by ROS 602 to execute processes that, while still needingsecurity, may not require the degree of security provided by SPU 500.This can be especially beneficial in architectures providing both an SPE503 and an HPE 655. The SPU 502 may be used to perform all truly secureprocessing, whereas one or more HPEs 655 may be used to provideadditional secure (albeit possibly less secure than the SPE) processingusing host processor or other general purpose resources that may beavailable within an electronic appliance 600. Any service may beprovided by such a secure HPE 655. In the preferred embodiment, certainaspects of “channel processing” appears to be a candidate that could bereadily exported from SPE 503 to HPE 655.

[0725] The software-based tamper resistant barrier 674 provided by HPE655 may be provided, for example, by: introducing time checks and/orcode modifications to complicate the process of stepping through codecomprising a portion of kernel 688 a and/or a portion of componentassemblies 690 using a debugger; using a map of defects on a storagedevice (e.g., a hard disk, memory card, etc.) to form internal testvalues to impede moving and/or copying HPE 655 to other electronicappliances 600; using kernel code that contains false branches and othercomplications in flow of control to disguise internal processes to somedegree from disassembly or other efforts to discover details ofprocesses; using “self-generating” code (based on the output of aco-sine transform, for example) such that detailed and/or completeinstruction sequences are not stored explicitly on storage devicesand/or in active memory but rather are generated as needed: using codethat “shuffles” memory locations used for data values based onoperational parameters to complicate efforts to manipulate such values:using any software and/or hardware memory management resources ofelectronic appliance 600 to “protect” the operation of HPE 655 fromother processes, functions, etc. Although such a software-based tamperresistant barrier 674 may provide a fair degree of security, ittypically will not be as secure as the hardware-based tamper resistantbarrier 502 provided (at least in part) by SPU 500. Because security maybe better/more effectively enforced with the assistance of hardwaresecurity features such as those provided by SPU 500 (and because ofother factors such as increased performance provided by special purposecircuitry within SPU 500), at least one SPE 503 is preferred for many ormost higher security applications. However, in applications where lessersecurity can be tolerated and/or the cost of an SPU 500 cannot betolerated, the SPE 503 may be omitted and all secure processing mayinstead be performed by one or more secure HPEs 655 executing ongeneral-purpose CPUs 654. Some VDE processes may not be allowed toproceed on reduced-security electronic appliances of this type ifinsufficient security is provided for the particular process involved.

[0726] Only those processes that execute completely within SPEs 503 (andin some cases, HPEs 655) may be considered to be truly secure. Memoryand other resources external to SPE 503 and HPEs 655 used to storeand/or process code and/or data to be used in secure processes shouldonly receive and handle that information in encrypted form unless SPE503/HPE 655 can protect secure process code and/or data from non-secureprocesses.

[0727] OS “core” 679 in the preferred embodiment includes a kernel 680,an RPC manager 732, and an “object switch” 734. API 682, HPE 655 and SPE503 may communicate “event” messages with one another via OS “core” 679.They may also communicate messages directly with one another withoutmessages going through OS “core” 679.

[0728] Kernel 680 may manage the hardware of an electronic appliance600. For example, it may provide appropriate drivers and hardwaremanagers for interacting with input/output and/or peripheral devicessuch as keyboard 612, display 614, other devices such as a “mouse”pointing device and speech recognizer 613, modem 618, printer 622, andan adapter for network 672. Kernel 680 may also be responsible forinitially loading the remainder of ROS 602, and may manage the variousROS tasks (and associated underlying hardware resources) duringexecution. OS kernel 680 may also manage and access secure database 610and file system 687. OS kernel 680 also provides execution services forapplications 608 a(1), 608 a(2), etc. and other applications.

[0729] RPC manager 732 performs messaging routing and resourcemanagement/integration for ROS 680. It receives and routes “calls”from/to API 682, HPE 655 and SPE 503, for example.

[0730] Object switch 734 may manage construction, deconstruction andother manipulation of VDE objects 300.

[0731] User Notification/Exception Interface 686 in the preferredembodiment (which may be considered part of API 682 or anotherapplication coupled to the API) provides “pop up” windows/displays ondisplay 614. This allows ROS 602 to communicate directly with a userwithout having to pass information to be communicated throughapplications 608. For applications that are not “VDE aware,” usernotification/exception interface 686 may provide communications betweenROS 602 and the user.

[0732] API 682 in the preferred embodiment provides a standardized,documented software interface to applications 608. In part, API 682 maytranslate operating system “calls” generated by applications 608 intoRemote Procedure Calls (“RPCs”) specifying “events.” RPC manager 732 mayroute these RPCs to kernel 680 or elsewhere (e.g., to HPE(s) 655 and/orSPE(s) 503, or to remote electronic appliances 600, processors, or VDEparticipants) for processing. The API 682 may also service RPC requestsby passing them to applications 608 that register to receive and processspecific requests.

[0733] API 682 provides an “Applications Programming Interface” that ispreferably standardized and documented. It provides a concise set offunction calls an application program can use to access servicesprovided by ROS 602. In at least one preferred example, API 682 willinclude two parts: an application program interface to VDE functions604; and an application program interface to other OS functions 606.These parts may be interwoven into the same software, or they may beprovided as two or more discrete pieces of software (for example).

[0734] Some applications, such as application 608 a(1) shown in FIG. 11,may be “VDE aware” and may therefore directly access both of these partsof API 682. FIG. 11A shows an example of this. A “VDE aware” applicationmay, for example, include explicit calls to ROS 602 requesting thecreation of new VDE objects 300, metering usage of VDE objects, storinginformation in VDE-protected form, etc. Thus, a “VDE aware” applicationcan initiate and, in some examples, enhance and/or extend) VDEfunctionality provided by ROS 602. In addition, “VDE aware” applicationsmay provide a more direct interface between a user and ROS 602 (e.g., bysuppressing or otherwise dispensing with “pop up” displays otherwiseprovided by user notification/exception interface 686 and insteadproviding a more “seamless” interface that integrates application andROS messages).

[0735] Other applications, such as application 608 b shown in FIG. 11B,may not be “VDE Aware” and therefore may not “know” how to directlyaccess an interface to VDE functions 604 provided by API 682. To providefor this, ROS 602 may include a “redirector” 684 that allows such“non-VDE aware” applications 608(b) to access VDE objects 300 andfunctions 604. Redirector 684, in the preferred embodiment, translatesOS calls directed to the “other OS functions” 606 into calls to the “VDEfunctions” 604. As one simple example, redirector 684 may intercept a“file open” call from application 608(b), determine whether the file tobe opened is contained within a VDE container 300, and if it is,generate appropriate VDE function call(s) to file system 687 to open theVDE container (and potentially generate events to HPE 655 and/or SPE 503to determine the name(s) of file(s) that may be stored in a VDE object300, establish a control structure associated with a VDE object 300,perform a registration for a VDE object 300, etc.). Without redirector684 in this example, a non-VDE aware application such as 608 b couldaccess only the part of API 682 that provides an interface to other OSfunctions 606, and therefore could not access any VDE functions.

[0736] This “translation” feature of redirector 684 provides“transparency.” It allows VDE functions to be provided to theapplication 608(b) in a “transparent” way without requiring theapplication to become involved in the complexity and details associatedwith generating the one or more calls to VDE functions 604. This aspectof the “transparency” features of ROS 602 has at least two importantadvantages:

[0737] (a) it allows applications not written specifically for VDEfunctions 604 (“non-VDE aware applications”) to nevertheless accesscritical VDE functions; and

[0738] (b) it reduces the complexity of the interface between anapplication and ROS 602.

[0739] Since the second advantage (reducing complexity) makes it easierfor an application creator to produce applications, even “VDE aware”applications 608 a(2) may be designed so that some calls invoking VDEfunctions 604 are requested at the level of an “other OS functions” calland then “translated” by redirector 684 into a VDE function call (inthis sense, redirector 684 may be considered a part of API 682). FIG.11C shows an example of this. Other calls invoking VDE functions 604 maybe passed directly without translation by redirector 684.

[0740] Referring again to FIG. 10, ROS 620 may also include an“interceptor” 692 that transmits and/or receives one or more real timedata feeds 694 (this may be provided over cable(s) 628 for example), androutes one or more such data feeds appropriately while providing“translation” functions for real time data sent and/or received byelectronic appliance 600 to allow “transparency” for this type ofinformation analogous to the transparency provided by redirector 684(and/or it may generate one or more real time data feeds).

[0741] Secure ROS Components and Component Assemblies

[0742] As discussed above, ROS 602 in the preferred embodiment is acomponent-based architecture. ROS VDE functions 604 may be based onsegmented, independently loadable executable “component assemblies” 690.These component assemblies 690 are independently securely deliverable.The component assemblies 690 provided by the preferred embodimentcomprise code and data elements that are themselves independentlydeliverable. Thus, each component assembly 690 provided by the preferredembodiment is comprised of independently securely deliverable elementswhich may be communicated using VDE secure communication techniques,between VDE secure subsystems.

[0743] These component assemblies 690 are the basic functional unitprovided by ROS 602. The component assemblies 690 are executed toperform operating system or application tasks. Thus, some componentassemblies 690 may be considered to be part of the ROS operating system602, while other component assemblies may be considered to be“applications” that ran under the support of the operating system. Aswith any system incorporating “applications” and “operating systems,”the boundary between these aspects of an overall system can beambiguous. For example, commonly used “application” functions (such asdetermining the structure and/or other attributes of a contentcontainer) may be incorporated into an operating system. Furthermore,“operating system” functions (such as task management, or memoryallocation) may be modified and/or replaced by an application. A commonthread in the preferred embodiment's ROS 602 is that componentassemblies 690 provide functions needed for a user to fulfill herintended activities, some of which may be “application-like” and some ofwhich may be “operating system-like.”

[0744] Components 690 are preferably designed to be easily separable andindividually loadable. ROS 602 assembles these elements together into anexecutable component assembly 690 prior to loading and executing thecomponent assembly (e.g., in a secure operating environment such as SPE503 and/or HPE 655). ROS 602 provides an element identification andreferencing mechanism that includes information necessary toautomatically assemble elements into a component assembly 690 in asecure manner prior to, and/or during, execution.

[0745] ROS 602 application structures and control parameters used toform component assemblies 690 can be provided by different parties.Because the components forming component assemblies 690 areindependently securely deliverable, they may be delivered at differenttimes and/or by different parties (“delivery” may take place within alocal VDE secure subsystem, that is submission through the use of such asecure subsystem of control information by a chain of content controlinformation handling participant for the preparation of a modifiedcontrol information set constitutes independent, secure delivery). Forexample, a content creator can produce a ROS 602 application thatdefines the circumstances required for licensing content containedwithin a VDE object 300. This application may reference structuresprovided by other parties. Such references might, for example, take theform of a control path that uses content creator structures to meteruser activities; and structures created/owned by a financial provider tohandle financial parts of a content distribution transaction (e.g.,defining a credit budget that must be present in a control structure toestablish creditworthiness, audit processes which must be performed bythe licensee, etc.). As another example, a distributor may give one usermore favorable pricing than another user by delivering different dataelements defining pricing to different users. This attribute ofsupporting multiple party securely, independently deliverable controlinformation is fundamental to enabling electronic commerce, that is,defining of a content and/or appliance control information set thatrepresents the requirements of a collection of independent parties suchas content creators, other content providers, financial serviceproviders, and/or users.

[0746] In the preferred embodiment, ROS 602 assembles securelyindependently deliverable elements into a component assembly 690 basedin part on context parameters (e.g., object, user). Thus, for example,ROS 602 may securely assemble different elements together to formdifferent component assemblies 690 for different users performing thesame task on the same VDE object 300. Similarly, ROS 602 may assemblediffering element sets which may include, that is reuse, one or more ofthe same components to form different component assemblies 690 for thesame user performing the same task on different VDE objects 300.

[0747] The component assembly organization provided by ROS 602 is“recursive” in that a component assembly 690 may comprise one or morecomponent “subassemblies” that are themselves independently loadable andexecutable component assemblies 690. These component “subassemblies”may, in turn, be made of one or more component “sub-sub-assemblies.” Inthe general case, a component assembly 690 may include N levels ofcomponent subassemblies.

[0748] Thus, for example, a component assembly 690(k) that may includesa component subassembly 690(k+1). Component subassembly 690(k+1), inturn, may include a component sub-sub-assembly 690(3), . . . and so onto N-level subassembly 690(k+N). The ability of ROS 602 to buildcomponent assemblies 690 out of other component assemblies providesgreat advantages in terms of, for example, code/data reusability, andthe ability to allow different parties to manage different parts of anoverall component.

[0749] Each component assembly 690 in the preferred embodiment is madeof distinct components. FIGS. 11D-11H are abstract depictions of variousdistinct components that may be assembled to form a component assembly690(k) showing FIG. 11I. These same components can be combined indifferent ways (e.g., with more or less components) to form differentcomponent assemblies 690 providing completely different functionalbehavior. FIG. 11J is an abstract depiction of the same components beingput together in a, different way (e.g., with additional components) toform a different component assembly 690(j). The component assemblies690(k) and 690(j) each include a common feature 691 that interlocks witha “channel” 594 defined by ROS 602. This “channel” 594 assemblescomponent assemblies 690 and interfaces them with the (rest of) ROS 602.

[0750] ROS 602 generates component assemblies 690 in a secure manner. Asshown graphically in FIGS. 11I and 11J, the different elementscomprising a component assembly 690 may be “interlocking” in the sensethat they can only go together in ways that are intended by the VDEparticipants who created the elements and/or specified the componentassemblies. ROS 602 includes security protections that can prevent anunauthorized person from modifying elements, and also prevent anunauthorized person from substituting elements. One can picture anunauthorized person making a new element having the same “shape” as theone of the elements shown in FIGS. 11D-11H, and then attempting tosubstitute the new element in place of the original element. Suppose oneof the elements shown in FIG. 11H establishes the price for usingcontent within a VDE object 300. If an unauthorized person couldsubstitute her own “price” element for the price element intended by theVDE content distributor, then the person could establish a price of zeroinstead of the price the content distributor intended to charge.Similarly, if the element establishes an electronic credit card, then anability to substitute a different element could have disastrousconsequences in terms of allowing a person to charge her usage tosomeone else's (or a non-existent) credit card. These are merely a fewsimple examples demonstrating the importance of ROS 602 ensuring thatcertain component assemblies 690 are formed in a secure manner. ROS 602provides a wide range of protections against a wide range of “threats”to the secure handling and execution of component assemblies 690.

[0751] In the preferred embodiment, ROS 602 assembles componentassemblies 690 based on the following types of elements:

[0752] Permissions Records (“PERC”s) 808;

[0753] Method “Cores” 1000;

[0754] Load Modules 1100;

[0755] Data Elements (e.g.. User Data Elements (“UDEs”) 1200 and MethodData Elements (“MDEs”) 1202); and

[0756] Other component assemblies 690.

[0757] Briefly, a PERC 808 provided by the preferred embodiment is arecord corresponding to a VDE object 300 that identifies to ROS 602,among other things, the elements ROS is to assemble together to form acomponent assembly 690. Thus PERC 808 in effect contains a “list ofassembly instructions” or a “plan” specifying what elements ROS 602 isto assemble together into a component assembly and how the elements areto be connected together. PERC 808 may itself contain data or otherelements that are to become part of the component assembly 690.

[0758] The PERC 808 may reference one or more method “cores” 1000′. Amethod core 1000′ may define a basic “method” 1000 (e.g., “control”“billing,” “metering,” etc.)

[0759] In the preferred embodiment, a “method” 1000 is a collection ofbasic instructions, and information related to basic instructions, thatprovides context, data, requirements, and/or relationships for use inperforming, and/or preparing to perform, basic instructions in relationto the operation of one or more electronic appliances 600. Basicinstructions may be comprised of, for example:

[0760] machine code of the type commonly used in the programming ofcomputers; pseudo-code for use by an interpreter or other instructionprocessing program operating on a computer;

[0761] a sequence of electronically represented logical operations foruse with an electronic appliance 600;

[0762] or other electronic representations of instructions, source code,object code, and/or pseudo code as those terms are commonly understoodin the arts.

[0763] Information relating to said basic instructions may comprise, forexample, data associated intrinsically with basic instructions such asfor example, an identifier for the combined basic instructions andintrinsic data, addresses, constants, and/or the like. The informationmay also, for example, include one or more of the following:

[0764] information that identifies associated basic instructions andsaid intrinsic data for access, correlation and/or validation purposes;

[0765] required and/or optional parameters for use with basicinstructions and said intrinsic data;

[0766] a information defining relationships to other methods;

[0767] data elements that may comprise data values, fields ofinformation, and/or the like;

[0768] information specifying and/or defining relationships among dataelements, basic instructions and/or intrinsic data;

[0769] information specifying relationships to external data elements;

[0770] information specifying relationships between and among internaland external data elements, methods, and/or the like, if any exist; and

[0771] additional information required in the operation of basicinstructions and intrinsic data to complete, or attempt to complete, apurpose intended by a user of a method, where required, includingadditional instructions and/or intrinsic data.

[0772] Such information associated with a method may be stored, in partor whole, separately from basic instructions and intrinsic data. Whenthese components are stored separately, a method may neverthelessinclude and encompass the other information and one or more sets ofbasic instructions and intrinsic data (the latter being included becauseof said other information's reference to one or more sets of basicinstructions and intrinsic data), whether or not said one or more setsof basic instructions and intrinsic data are accessible at any givenpoint in time.

[0773] Method core 1000′ may be parameterized by an “event code” topermit it to respond to different events in different ways. For example,a METER method may respond to a “use” event by storing usage informationin a meter data structure. The same METER method may respond to an“administrative” event by reporting the meter data structure to a VDEclearinghouse or other VDE participant.

[0774] In the preferred embodiment, method core 1000′ may “contain,”either explicitly or by reference, one or more “load modules” 1100 andone or more data elements (UDEs 1200, MDEs 1202). In the preferredembodiment, a “load module” 1100 is a portion of a method that reflectsbasic instructions and intrinsic data. Load modules 1100 in thepreferred embodiment contain executable code, and may also contain dataelements (“DTDs” 1108) associated with the executable code. In thepreferred embodiment, load modules 1100 supply the program instructionsthat are actually “executed” by hardware to perform the process definedby the method. Load modules 1100 may contain or reference other loadmodules.

[0775] Load modules 1100 in the preferred embodiment are modular and“code pure” so that individual load modules may be reenterable andreusable. In order for components 690 to be dynamically updatable, theymay be individually addressable within a global public name space. Inview of these design goals, load modules 1100 are preferably small, code(and code-like) pure modules that are individually named andaddressable. A single method may provide different load modules 1100that perform the same or similar functions on different platforms,thereby making the method scalable and/or portable across a wide rangeof different electronic appliances.

[0776] UDEs 1200 and MDEs 1202 may store data for input to or outputfrom executable component assembly 690 (or data describing such inputsand/or outputs). In the preferred embodiment, UDEs 1200 may be userdependent, whereas MDEs 1202 may be user independent.

[0777] The component assembly example 690(k) shown in FIG. 11E comprisesa method core 1000′, UDEs 1200 a & 1200 b, an MDE 1202, load modules1100 a-1100 d, and a further component assembly 690(k+1). As mentionedabove, a PERC 808(k) defines. among other things, the “assemblyinstructions” for component assembly 690(k), and may contain orreference parts of some or all of the components that are to beassembled to create a component assembly.

[0778] One of the load modules 1100 b shown in this example is itselfcomprised of plural load modules 1100 c, 1100 d. Some of the loadmodules (e.g., 1100 a, 1100 d) in this example include one or more “DTD”data elements 1108 (e.g., 1108 a, 1108 b). “DTD” data elements 1108 maybe used, for example, to inform load module 1100 a of the data elementsincluded in MDE 1202 and/or UDEs 1200 a, 1200 b. Furthermore, DTDs 1108may be used as an aspect of forming a portion of an application used toinform a user as to the information required and/or manipulated by oneor more load modules 1100, or other component elements. Such anapplication program may also include functions for creating and/ormanipulating UDE(s) 1200, MDE(s) 1202, or other component elements,subassemblies, etc.

[0779] Components within component assemblies 690 may be “reused” toform different component assemblies. As mentioned above, FIG. 11F is anabstract depiction of one example of the same components used forassembling component assembly 690(k) to be reused (e.g., with someadditional components specified by a different set of “assemblyinstructions” provided in a different PERC 808(l)) to form a differentcomponent assembly 690(l). Even though component assembly 690(l) isformed from some of the same components used to form component assembly690(k), these two component assemblies may perform completely differentprocesses in complete different ways.

[0780] As mentioned above, ROS 602 provides several layers of securityto ensure the security of component assemblies 690. One importantsecurity layer involves ensuring that certain component assemblies 690are formed, loaded and executed only in secure execution space such asprovided within an SPU 500. Components 690 and/or elements comprisingthem may be stored on external media encrypted using local SPU 500generated and/or distributor provided keys.

[0781] ROS 602 also provides a tagging and sequencing scheme that may beused within the loadable component assemblies 690 to detect tampering bysubstitution. Each element comprising a component assembly 690 may beloaded into an SPU 500, decrypted using encrypt/decrypt engine 522, andthen tested/compared to ensure that the proper element has been loaded.Several independent comparisons may be used to ensure there has been nounauthorized substitution. For example, the public and private copies ofthe element ID may be compared to ensure that they are the same, therebypreventing gross substitution of elements. In addition, avalidation/correlation tag stored under the encrypted layer of theloadable element may be compared to make sure it matches one or moretags provided by a requesting process. This prevents unauthorized use ofinformation. As a third protection, a device assigned tag (e.g., asequence number) stored under an encryption layer of a loadable elementmay be checked to make sure it matches a corresponding tag valueexpected by SPU 500. This prevents substitution of older elements.Validation/correlation tags are typically passed only in secure wrappersto prevent plaintext exposure of this information outside of SPU 500.

[0782] The secure component based architecture of ROS 602 has importantadvantages. For example, it accommodates limited resource executionenvironments such as provided by a lower cost SPU 500. It also providesan extremely high level of configurability. In fact, ROS 602 willaccommodate an almost unlimited diversity of content types, contentprovider objectives, transaction types and client requirements. Inaddition, the ability to dynamically assemble independently deliverablecomponents at execution time based on particular objects and usersprovides a high degree of flexibility, and facilitates or enables adistributed database, processing, and execution environment.

[0783] One aspect of an advantage of the component-based architectureprovided by ROS 602 relates to the ability to “stage” functionality andcapabilities over time. As designed, implementation of ROS 602 is afinite task. Aspects of its wealth of functionality can remainunexploited until market realities dictate the implementation ofcorresponding VDE application functionality. As a result, initialproduct implementation investment and complexity may be limited. Theprocess of “surfacing” the full range of capabilities provided by ROS602 in terms of authoring, administrative, and artificial intelligenceapplications may take place over time. Moreover, already-designedfunctionality of ROS 602 may be changed or enhanced at any time to adaptto changing needs or requirements.

[0784] More Detailed Discussion of Rights Operating System 602Architecture

[0785]FIG. 12 shows an example of a detailed architecture of ROS 602shown in FIG. 10. ROS 602 may include a file system 687 that includes acommercial database manager 730 and external object repositories 728.Commercial database manager 730 may maintain secure database 610. Objectrepository 728 may store, provide access to, and/or maintain VDE objects300.

[0786]FIG. 12 also shows that ROS 602 may provide one or more SPEs 503and/or one or more HPEs 655. As discussed above, HPE 655 may “emulate”an SPU 500 device, and such HPEs 655 may be integrated in lieu of (or inaddition to) physical SPUs 500 for systems that need higher throughput.Some security may be lost since HPEs 655 are typically protected byoperating system security and may not provide truly secure processing.Thus, in the preferred embodiment, for high security applications atleast, all secure processing should take place within an SPE 503 havingan execution space within a physical SPU 500 rather than a HPE 655 usingsoftware operating elsewhere in electronic appliance 600.

[0787] As mentioned above, three basic components of ROS 602 are akernel 680, a Remote Procedure Call (RPC) manager 732 and an objectswitch 734. These components, and the way they interact with otherportions of ROS 602. will be discussed below.

[0788] Kernel 680

[0789] Kernel 680 manages the basic hardware resources of electronicappliance 600, and controls the basic tasking provided by ROS 602.Kernel 680 in the preferred embodiment may include a memory manager 680a, a task manager 680 b, and an I/O manager 680 c. Task manager 680 bmay initiate and/or manage initiation of executable tasks and schedulethem to be executed by a processor on which ROS 602 runs (e.g., CPU 654shown in FIG. 8). For example, Task manager 680 b may include or beassociated with a “bootstrap loader” that loads other parts of ROS 602.Task manager 680 b may manage all tasking related to ROS 602, includingtasks associated with application program(s) 608. Memory manager 680 amay manage allocation, deallocation, sharing and/or use of memory (e.g.,RAM 656 shown in FIG. 8) of electronic appliance 600, and may forexample provide virtual memory capabilities as required by an electronicappliance and/or associated application(s). I/O manager 680 c may manageall input to and output from ROS 602, and may interact with drivers andother hardware managers that provide communications and interactivitywith physical devices.

[0790] RPC Manager 732

[0791] ROS 602 in a preferred embodiment is designed around a “servicesbased” Remote Procedure Call architecture/interface. Alu functionsperformed by ROS 602 may use this common interface to request servicesand share information. For example, SPE(s) 503 provide processing forone or more RPC based services. In addition to supporting SPUs 500, theRPC interface permits the dynamic integration of external services andprovides an array of configuration options using existing operatingsystem components. ROS 602 also communicates with external servicesthrough the RPC interface to seamlessly provide distributed and/orremote processing. In smaller scale instances of ROS 602, a simplermessage passing IPC protocol may be used to conserve resources. This maylimit the configurability of ROS 602 services, but this possiblelimitation may be acceptable in some electronic appliances.

[0792] The RPC structure allows services to be called/requested withoutthe calling process having to know or specify where the service isphysically provided, what system or device will service the request, orhow the service request will be fed. This feature supports families ofservices that may be scaled and/or customized for specific applications.Service requests can be forwarded and serviced by different processorsand/or different sites as easily as they can be forwarded and servicedby a local service system. Since the same RPC interface is used by ROS602 In the preferred embodiment to request services within and outsideof the operating system, a request for distributed and/or remoteprocessing incurs substantially no additional operating system overhead.Remote processing is easily and simply integrated as part of the sameservice calls used by ROS 602 for requesting local-based services. Inaddition, the use of a standard RPC interface (CRSIG) allows ROS 602 tobe modularized, with the different modules presenting a standardizedinterface to the remainder of the operating system. Such modularizationand standardized interfacing permits different vendors/operating systemprogrammers to create different portions of the operating systemindependently, and also allows the functionality of ROS 602 to beflexibly updated and/or changed based on different requirements and/orplatforms.

[0793] RPC manager 732 manages the RPC interface. It receives servicerequests in the form of one or more “Remote Procedure Calls” (RPCs) froma service requester, and routes the service requests to a serviceprovider(s) that can service the request. For example, when rightsoperating system 602 receives a request from a user application via userAPI 682, RPC manager 732 may route the service request to an appropriateservice through the “RPC service interface” (“RSI”). The RSI is aninterface between RPC manager 732, service requesters, and a resourcethat will accept and service requests.

[0794] The RPC interface (RSI) is used for several major ROS 602subsystems in the preferred embodiment.

[0795] RPC services provided by ROS 602 in the preferred embodiment aredivided into subservices, i.e., individual instances of a specificservice each of which may be tracked individually by the RPC manager732. This mechanism permits multiple instances of a specific service onhigher throughput systems while maintaining a common interface across aspectrum of implementations. The subservice concept extends tosupporting multiple processors, multiple SPEs 503, multiple HPEs 655,and multiple communications services.

[0796] The preferred embodiment ROS 602 provides the following RPC basedservice providers/requestors (each of which have an RPC interface or“RSI” that communicates with RPC manager 732):

[0797] SPE device driver 736 (this SPE device driver is connected to anSPE 503 in the preferred embodiment);

[0798] HPE Device Driver 738 (this HPE device driver is connected to anHPE 738 in the preferred embodiment);

[0799] Notification Service, 740 (this notification service is connectedto user notification interface 686 in the preferred embodiment);

[0800] API Service 742 (this API service is connected to user API 682 inthe preferred embodiment;

[0801] Redirector 684;

[0802] Secure Database (File) Manager 744 (this secure database or filemanager 744 may connect to and interact with commercial database manager730 and secure files 610 through a cache manager 746, a databaseinterface 748, and a database driver 750);

[0803] Name Services Manager 752;

[0804] Outgoing Administrative Objects Manager 754;

[0805] Incoming Administrative Objects Manager 756;

[0806] a Gateway 734 to object switch 734 (this is a path used to allowdirect communication between RPC manager 732 and Object Snitch 734); and

[0807] Communications Manager 776.

[0808] The types of services provided by HPE 655. SPE 503, UserNotification 686, API 742 and Redirector 684 have already been describedabove. Here is a brief description of the type(s) of services providedby OS resources 744, 752, 754, 756 and 776:

[0809] Secure Database Manager 744 services requests for access tosecure database 610;

[0810] Name Services Manager 752 services requests relating to user,host, or service identification;

[0811] Outgoing Administrative Objects Manager 754 services requestsrelating to outgoing administrative objects;

[0812] Incoming Administrative Objects Manager 756 services requestsrelating to incoming administrative objects; and

[0813] Communications Manager 776 services requests relating tocommunications between electronic appliance 600 and the outside world.

[0814] Object Switch 734

[0815] Object switch 734 handles, controls and communicates (bothlocally and remotely) VDE objects 300. In the preferred embodiment, theobject switch may include the following elements:

[0816] a stream router 758;

[0817] a real time stream interfaces 760 (which may be connected to realtime data feed(s) 694);

[0818] a time dependent stream interface(s) 762;

[0819] a intercept 6929

[0820] a container manager 764;

[0821] one or more routing tables 766; and

[0822] buffering/storage 768.

[0823] Stream router 758 routes to/from “real time” and “timeindependent” data streams handled respectively by real time streaminterface(s) 760 and time dependent stream interface(s) 762. Intercept692 intercepts I/O requests that involve real-time information streamssuch as, for example, real time feed 694. The routing performed bystream router 758 may be determined by routing tables 766.Buffering/storage 768 provides temporary store-and-forward, bufferingand related services. Container manager 764 may (typically inconjunction with SPE 503) perform processes on VDE objects 300 such asconstructing, deconstructing, and locating portions of objects.

[0824] Object switch 734 communicates through an Object Switch Interface(“OSI”) with other parts of ROS 602. The Object Switch Interface mayresemble, for example, the interface for a Unix socket in the preferredembodiment. Each of the “OSI” interfaces shown in FIG. 12 have theability to communicate with object switch 734.

[0825] ROS 602 includes the following object switch serviceproviders/resources (each of which can communicate with the objectswitch 734 through an “OSI”):

[0826] Outgoing Administrative Objects Manager 754;

[0827] Incoming Administrative Objects Manager 756;

[0828] Gateway 734 (which may translate RPC calls into object switchcalls and vice versa so RPC manager 732 may communicate with objectswitch 734 or any other element having an OSI to, for example, provideand/or request services);

[0829] External Services Manager 772;

[0830] Object Submittal Manager 774; and

[0831] Communications Manager 776.

[0832] Briefly,

[0833] Object Repository Manager 770 provides services relating toaccess to object repository 728;

[0834] External Services Manager 772 provides services relating torequesting and receiving services externally, such as from a networkresource or another site;

[0835] Object Submittal Manager 774 provides services relating to how auser application may interact with object switch 734 (since the objectsubmittal manager provides an interface to an application program 608,it could be considered part of user API 682); and

[0836] Communications Manager 776 provides services relating tocommunicating with the outside world.

[0837] In the preferred embodiment, communications manager 776 mayinclude a network manager 780 and a mail gateway (manager) 782. Mailgateway 782 may include one or more mail filters 784 to, for example,automatically route VDE related electronic mail between object switch734 and the outside world electronic mail services. External ServicesManager 772 may interface to communications manager 776 through aService Transport Layer 786. Service Transport Layer 786a may enableExternal Services Manager 772 to communicate with external computers andsystems using various protocols managed using the service transportlayer 786.

[0838] The characteristics of and interfaces to the various subsystemsof ROS 680 shown in FIG. 12 are described in more detail below.

[0839] RPC Manager 732 and Its RPC Services Interface

[0840] As discussed above, the basic system services provided by ROS 602are invoked by using an RPC service interface (RSI). This RPC serviceinterface provides a generic, standardized interface for differentservices systems and subsystems provided by ROS 602.

[0841] RPC Manager 732 routes RPCs requesting services to an appropriateRPC service interface. In the preferred embodiment, upon receiving anRPC call, RPC manager 732 determines one or more service managers thatare to service the request. RPC manager 732 then routes a servicerequest to the appropriate service(s) (via a RSI associated with aservice) for action by the appropriate service manager(s).

[0842] For example, if a SPE 503 is to service a request, the RPCManager 732 routes the request to RSI 736 a, which passes the request onto SPE device driver 736 for forwarding to the SPE. Similarly, if HPE655 is to service the request, RPC Manager 732 routes the request to RSI738 a for forwarding to a HPE. In one preferred embodiment, SPE 503 andHPE 655 may perform essentially the same services so that RSIs 736 a,738 a are different instances of the same RSI. Once a service requesthas been received by SPE 503 (or HPE 655), the SPE (or HPE typicallydispatches the request internally using its own internal RPC manager (aswill be discussed shortly). Processes within SPEs 503 and HPEs 655 canalso generate RPC requests. These SVC_WRITE Write a block to an openedsubservice. SVC_IOCTL Control a subservice or a service manager.

[0843]

[0844] Load

[0845] In the preferred embodiment, services (and the associated RSIsthey present to RPC manager 732) may be activated during boot by aninstallation boot process that issues an RPC LOAD. This process reads anRPC Services Table from a configuration file, loads the service moduleif it is run time loadable (as opposed to being a kernel linked devicedriver), and then calls the LOAD entry point for the service. Asuccessful return from the LOAD entry point will indicate that theservice has properly loaded and is ready to accept requests.

[0846] RPC LOAD Call Example: SVC_LOAD (Long service_id)

[0847] This LOAD interface call is called by the RPC manager 732 duringrights operating system 602 initialization. It permits a service managerto load any dynamically loadable components and to initialize any deviceand memory required by the service. The service number that the serviceis loaded as is passed in as service_id parameter. In the preferredembodiment, the service

[0848] RPC READ Call Example:

[0849] SVC_READ (long svc_handle, long request_id, BYTE *buffer, longsize)

[0850] This READ call reads a message response from a service. Thesvc_handle and request_id parameters uniquely identify a request. Theresults of a request will be stored in the user specified buffer up tosize bytes. If the buffer is too small, the first size bytes of themessage will be stored in the buffer and an error will be returned.

[0851] If a message response was returned to the caller's buffercorrectly, the function will return 0. Otherwise, an error message willbe returned.

[0852] RPC WRITE Call Example:

[0853] SVC_write (long service_id, long subservice_id, BYTE *buffer,long size, int (*receive) (long request_id)

[0854] This WRITE call writes a message to a service and subservicespecified by the service_id subservice_id parameter pair. The message isstored in buffer (and usually conforms to the VDE RPC message format)and is size bytes long. The function returns the request id for themessage (if it was accepted for sending) or an error number. If a userspecifies the receive callback functions, all messages regarding arequest will Command Structure Description GET_INFO SVC_INFO Returnsinformation about a service/subservice. GET_STATS SVC_STATS Returnscurrent statistics about a service/subservice. CLR_STATS None Clears thestatistics about a service/subservice.

[0855] Now that a generic RPC Service Interface provided by thepreferred embodiment has been described, the following descriptionrelates to particular examples of services provided by ROS 602.

[0856] SPE Device Driver 736

[0857] SPE device driver 736 provides an interface between ROS 602 andSPE 503. Since SPE 503 in the preferred embodiment runs within theconfines of an SPE 500, one aspect of this device driver 736 is toprovide low level communications services with the SPU, 500 hardware.Another aspect of SPE device driver 736 is to provide an RPC serviceinterface (RSI) 736 a particular to SPE 503 (this same RSI may be usedto communicate with HPE 655 through HPE device driver 738)

[0858] SPE RSI 736 a and driver 736 isolates calling processes withinROS 602 (or external to the ROS) from the detailed service provided bythe SPE 503 by providing a set of basic interface points providing aconcise function set. This has several advantages. For example, itpermits a full line of scaled SPUs 500 that all provide commonfunctionality to the outside world but which may differ in detailedinternal structure and architecture. SPU 500 characteristics such as theamount of memory resident in the device, processor speed, and the numberof services supported within SPU, 500 may be the decision of thespecific SPU manufacturer, and in any event may differ from one SPUconfiguration to another. To maintain compatibility, SPE device driver736 and the RSI 736 a it provides conform to a basic common RPCinterface standard that “hides” differences between detailedconfigurations of SPUs 500 and/or the SPEs 503 they may support.

[0859] To provide for such compatibility, SPE RSI 736 a in the preferredembodiment follows a simple block based standard. In the preferredembodiment, an SPE RSI 736 a may be modeled after the packet interfacesfor network Ethernet cards. This standard closely models the block modeinterface characteristics of SPUs 500 in the preferred embodiment.

[0860] An SPE RSI 736 a allows RPC calls from RPC manager 732 to accessspecific services provided by an SPE 736. To do this, SPE RSI 736 aprovides a set of “service notification address interfaces.” Theseprovide interfaces to individual services provided by SPE 503 to theoutside world. Any calling process within ROS 602 may access theseSPE-provided services by directing an RPC call to SPE RSI 736 a andspecifying a corresponding “service notification address” in an RPCcall. The specified “service notification address” causes SPE 503 tointernally route an RPC call to a particular service within an SPE. Thefollowing is a listing of one example of a SPE service breakdown forwhich individual service notification addresses may be provided:

[0861] Channel Services Manager

[0862] Authentication Manager/Secure Communications Manager

[0863] Secure Database Manager

[0864] The Channel Services Manager is the principal service providerand access point to SPE 503 for the rest of ROS 602. Event processing,as will be discussed later, is primarily managed (from the point of viewof processes outside SPE 503) by this service. The AuthenticationManager/Secure Communications Manager may provide login/logout servicesfor users of ROS 602, and provide a direct service for managingcommunications (typically encrypted or otherwise protected) related tocomponent assemblies 690, VDE objects 300, etc. Requests for display ofinformation (e.g., value remaining in a financial budget) may beprovided by a direct service request to a Secure Database Manager insideSPE 503. The instances of Authentication Manager/Secure CommunicationsManager and Secure Database Manager, if available at all, may provideonly a subset of the information and/or capabilities available toprocesses operating inside SPE 503. As stated above, most (potentiallyall) service requests entering SPE are routed to a Channel ServicesManager for processing. As will be discussed in more detail later on,most control structures and event processing logic is associated withcomponent assemblies 690 under the management of a Channel ServicesManager.

[0865] The SPE 503 must be accessed through its associated SPE driver736 in this example. Generally, calls to SPE driver 736 are made inresponse to RPC calls. In this example, SPE driver RSI 736 a maytranslate RPC calls directed to control or ascertain information aboutSPE driver 736 into driver calls. SPE driver RSI 736 a in conjunctionwith driver 736 may pass RPC calls directed to SPE 503 through to theSPE.

[0866] The following table shows one example of SPE device driver 736calls: Entry Point Description SPE_info( ) Returns summary informationabout the SPE driver 736 (and SPE 503) SPE_initialize_interface( )Initializes SPE driver 736, and sets the default notification addressfor received packets. SPE_terminate_interface( ) Terminates SPE driver736 and resets SPU 500 and the driver 736. SPE_reset_interface( ) Resetsdriver 736 without resetting SPU 500. SPE_get_stats( ) Return statisticsfor notification addresses and/or an entire driver 736. SPE_clear_stats() Clear statistics for a specific notification address and/or an entiredriver 736. SPE_set_notify( ) Sets a notification address for a specificservice ID. SPE_get_notify( ) Returns a notification address for aspecific service ID SPE_tx_pkt( ) Sends a packet (e.g., containing anRPC call) to SPE 503 for processing

[0867] The following are more detailed examples of each of the SPEdriver calls set forth in the table above.

[0868] Example of an “SPE Information” Driver Call: SPE_info (Void)

[0869] This function returns a pointer to an SPE_INFO data structurethat defines the SPE device driver 736 a. This data structure mayprovide certain information about SPE device driver 736, RSI 736 aand/or SPU 500. An example of a SPE_INFO structure is described below:Version Number/ID for SPE Device Driver 736 Version Number/ID for SPEDevice Driver RSI 736 Pointer to name of SPE Device Driver 736 Pointerto ID name of SPU 500 Functionality Code Describing SPECapabilities/functionality

[0870] Example of an SPE “Initialize Interface” Driver Call:SPE_intialize_interface (int (fcn *Receiver)(Void))

[0871] A receiver function passed in by way of a parameter will becalled for all packets received from SPE 503 unless their destinationservice is over-ridden using the set_notify( ) call. A receiver functionallows ROS 602 to specify a format for packet communication between RPCmanager 732 and SPE 503.

[0872] This function returns “0” in the preferred embodiment if theinitialization of the interface succeeds and non-zero if it fails. Ifthe function fails, it will return a code that describes the reason forthe failure as the value of the function.

[0873] Example of an SPE “Terminate Interface” Driver Call:SPE_terminate_interface (Void)

[0874] In the preferred embodiment, this function shuts down SPE Driver736, clears all notification addresses, and terminates all outstandingrequests between an SPE and an ROS RPC manager 732. It also resets anSPE 503 (e.g., by a warm reboot of SPU 500) after all requests areresolved.

[0875] Termination of driver 736 should be performed by ROS 602 when theoperating system is starting to shut down. It may also be necessary toissue this call if an SPE 503 and ROS 602 get so far out ofsynchronization that all processing in an SPE must be reset to a knownstate.

[0876] Example of an SPE “Reset Interface” Driver Call:SPE_reset_interface (Void)

[0877] This function resets driver 736, terminates all outstandingrequests between SPE 503 and an ROS RPC manager 732, and clears allstatistics counts. It does not reset the SPU 500, but simply restoresdriver 736 to a known stable state.

[0878] Example of an SPE “Get Statistics” Driver Call: SPE_get_stats(Long service_id)

[0879] This function returns statistics for a specific servicenotification interface or for the SPE driver 736 in general. It returnsa pointer to a static buffer that contains these statistics or NULL ifstatistics are unavailable (either because an interface is notinitialized or because a receiver address was not specified). An exampleof the SPE_STATS structure may have the following definition: Service id# packets rx # packets tx # bytes rx # bytes tx # errors rx

[0880] If a user specifies a service ID, statistics associated withpackets sent by that service are returned. If a user specified 0 as theparameter, the total packet statistics for the interface are returned.

[0881] Example of an SPE “Clear Statistics” Driver Call: SPE_clear_stats(Long service_id)

[0882] This function clears statistics associated with the SPEservice_id specified. If no service_id is specified (i.e., the callerpasses in 0), global statistics will be cleared. The function returns 0if statistics are successfully cleared or an error number if an erroroccurs.

[0883] Example of an SPE “Set Notification Address” Driver Call:SPE_set_notify (Long service_id, int (fcn *Receiver) (Void))

[0884] This function sets a notification address (receiver) for aspecified service. If the notification address is set to NULL, SPEdevice driver 736 will send notifications for packets to the specifiedservice to the default notification address.

[0885] Example of a SPE “Get Notification Address” Driver Call:SPE_get_notify (Long service_id)

[0886] This function returns a notification address associated with thenamed service or NULL if no specific notification address has beenspecified.

[0887] Example of an SPE “Send Packet” Driver Call:

[0888] send_pkt (BYTE *buffer, long size, int (far *receive) (void))

[0889] This function sends a packet stored in buffer of “length” size.It returns 0 if the packet is sent successfully, or returns an errorcode associated with the failure.

[0890] Redirector Service Manager 684

[0891] The redirector 684 is a piece of systems integration softwareused principally when ROS 602 is provided by “adding on” to apre-existing operating system or when “transparent” operation is desiredfor some VDE functions, as described earlier. In one embodiment thekernel 680, part of communications manager 776, file system 687, andparc of API service 742 may be part of a pre-existing operating systemsuch as DOS, Windows, UNIX, Macintosh System, OS9, PSOS, OS/2, or otheroperating system platform. The remainder of ROS 602 subsystems shown inFIG. 12 may be provided as an “add on” to a preexisting operatingsystem. Once these ROS subsystems have been supplied and “added on,” theintegrated whole comprises the ROS 602 shown in FIG. 12.

[0892] In a scenario of this type of integration, ROS 602 will continueto be supported by a preexisting OS kernel 680, but may supplement (oreven substitute) many of its functions by providing additional add-onpieces such as, for example, a virtual memory manager.

[0893] Also in this integration scenario, an add-on portion of APIservice 742 that integrates readily with a preexisting API service isprovided to support VDE function calls. A pre-existing API serviceintegrated with an add-on portion supports an enhanced set of operatingsystem calls including both calls to VDE functions 604 and calls tofunctions 606 other than VDE functions (see FIG. 11A). The add-onportion of API service 742 may translate VDE function calls into RPCcalls for routing by RPC manager 732.

[0894] ROS 602 may use a standard communications manager 776 provided bythe preexisting operating system, or it may provide “add ons” and/orsubstitutions to it that may be readily integrated into it. Redirector684 may provide this integration function.

[0895] This leaves a requirement for ROS 602 to integrate with apreexisting file system 687. Redirector 684 provides this integrationfunction.

[0896] In this integration scenario, file system 687 of the preexistingoperating system is used for all accesses to secondary storage. However,VDE objects 300 may be stored on secondary storage in the form ofexternal object repository 728, file system 687, or remotely accessiblethrough communications manager 776. When object switch 734 wants toaccess external object repository 728, it makes a request to the objectrepository manager 770 that then routes the request to object repository728 or to redirector 692 (which in turn accesses the object in filesystem 687).

[0897] Generally, redirector 684 maps VDE object repository 728 contentinto preexisting calls to file system 687. The redirector 684 providespreexisting OS level information about a VDE object 300, includingmapping the object into a preexisting OS's name space. This permitsseamless access to VDE protected content using “normal” file system 687access techniques provided by a preexisting operating system.

[0898] In the integration scenarios discussed above, each preexistingtarget OS file system 687 has different interface requirements by whichthe redirector mechanism 684 may be “hooked.” In general, since allcommercially viable operating systems today provide support for networkbased volumes, file systems, and other devices (e.g., printers, modems,etc.), the redirector 684 may use low level network and file access“hooks” to integrate with a preexisting operating system. “Add-ons” forsupporting VDE functions 602 may use these existing hooks to integratewith a preexisting operating system.

[0899] User Notification Service Manager 740

[0900] User Notification Service Manager 740 and associated usernotification exception interface (“pop up”) 686 provides ROS 602 with anenhanced ability to communicate with a user of electronic appliance 600.Not all applications 608 may be designed to respond to messaging fromROS 602 passed through API 682, and it may in any event be important ordesirable to give ROS 602 the ability to communicate with a user nomatter what state an application is in. User notification servicesmanager 740 and interface 686 provides ROS 602 with a mechanism tocommunicate directly with a user, instead of or in addition to passing areturn call through API 682 and an application 608. This is similar, forexample, to the ability of the Windows operating system to display auser message in a “dialog box” that displays “on top of” a runningapplication irrespective of the state of the application.

[0901] The User Notification 686 block in the preferred embodiment maybe implemented as application code. The implementation of interface 740a is preferably built over notification service manager 740, which maybe implemented as part of API service manager 742. Notification servicesmanager 740 in the preferred embodiment provides notification support todispatch specific notifications to an appropriate user process via theappropriate API return, or by another path. This mechanism permitsnotifications to be routed to any authorized process—not just back to aprocess that specified a notification mechanism.

[0902] API Service Manager 742

[0903] The preferred embodiment API Service Manager 742 is implementedas a service interface to the RPC service manager 732. All user APIrequests are built on top of this basic interface. The API ServiceManager 742 preferably provides a service instance for each running userapplication 608.

[0904] Most RPC calls to ROS functions supported by API Service Manager742 in the preferred embodiment may map directly to service calls withsome additional parameter checking. This mechanism permits developers tocreate their own extended API libraries with additional or changedfunctionality.

[0905] In the scenario discussed above in which ROS 602 is formed byintegrating “add ons” with a preexisting operating system, the APIservice 42 code may be shared (e.g., resident in a host environment likea Windows DLL), or it may be directly, linked with an applications'scode—depending on an application programmer's implementation decision,and/or the type of electronic appliance 600. The Notification ServiceManager 740 may be implemented within API 682. These componentsinterface with Notification Service component 686 to provide atransition between system and user space.

[0906] Secure Database Service Manager (“SDSM”) 744

[0907] There are at least two ways that may be used for managing securedatabase 600:

[0908] a commercial database approach, and

[0909] a site record number approach.

[0910] Which way is chosen may be based on the number of records that aVDE site stores in the secure database 610.

[0911] The commercial database approach uses a commercial database tostore securely wrappered records in a commercial database. This way maybe preferred when there are a large number of records that are stored inthe secure database 610. This way provides high speed access, efficientupdates, and easy integration to host systems at the cost of resourceusage (most commercial database managers use many system resources).

[0912] The site record number approach uses a “site record number”(“SRN”) to locate records in the system. This scheme is preferred whenthe number of records stored in the secure database 610 is small and isnot expected to change extensively over time. This way providesefficient resources use with limited update capabilities. SRNs permitfurther grouping of similar data records to speed access and increaseperformance.

[0913] Since VDE 100 is highly scalable, different electronic appliances600 may suggest one way more than the other. For example, in limitedenvironments like a set top, PDA, or other low end electronic appliance,the SRN scheme may be preferred because it limits the amount ofresources (memory and processor) required. When VDE is deployed on morecapable electronic appliances 600 such as desktop computers, servers andat clearinghouses, the commercial database scheme may be more desirablebecause it provides high performance in environments where resources arenot limited.

[0914] One difference between the database records in the two approachesis whether the records are specified using a full VDE ID or SRN. Totranslate between the two schemes, a SRN reference may be replaced witha VDE ID database reference wherever it occurs. Similarly, VDE IDs thatare used as indices or references to other items may be replaced by theappropriate SRN value.

[0915] In the preferred embodiment, a commercially available databasemanager 730 is used to maintain secure database 610 ROS 602 interactswith commercial database manager 730 through a database driver 750 and adatabase interface 748. The database interface 748 between ROS 602 andexternal, third party database vendors' commercial database manager 730may be an open standard to permit any database vendor to implement a VDEcompliant database driver 750 for their products.

[0916] ROS 602 may encrypt each secure database 610 record so that aVDE-provided security layer is “on top of” the commercial databasestructure. In other words, SPE 736 may write secure records in sizes andformats that may be stored within a database record structure supportedby commercial database manager 730. Commercial database manager 730 maythen be used to organize, store, and retrieve the records. In someembodiments, it may be desirable to use a proprietary and or newlycreated database manager in place of commercial database manager 730.However, the use of commercial database manager 730 may provide certainadvantages such as, for example, an ability to use already existingdatabase management product(s).

[0917] The Secure Database Services Manager (“SDSM”) 744 makes calls toan underlying commercial database manager 730 to obtain, modify, andstore records in secure database 610 In the preferred embodiment, “SDSM”744 provides a layer “on top of” the structure of commercial databasemanager 730. For example, all VDE-secure information is sent tocommercial database manager 730 in encrypted form. SDSM 744 inconjunction with cache manager 746 and database interface 748 mayprovide record management, caching (using cache manager 746), andrelated services (on top of) commercial database systems 730 and/orrecord managers. Database Interface 748 and cache manager 746 in thepreferred embodiment do not present their own RSI, but rather the RPCManager 732 communicates to them through the Secure Database Manager RSI744 a.

[0918] Name Services Manager 752

[0919] The Name Services Manager 752 supports three subservices: username services, host name services, and services name services. User nameservices provides mapping and lookup between user name and user IDnumbers, and may also support other aspects of user-based resource andinformation security. Host name services provides mapping and lookupbetween the names (and other information, such as for example address,communications connection/routing information, etc.) of other processingresources (e.g., other host electronic appliances) and VDE node IDs.Services name service provides a mapping and lookup between servicesnames and other pertinent information such as connection information(e.g., remotely available service routing and contact information) andservice IDs.

[0920] Name Services Manager 752 in the preferred embodiment isconnected to External Services Manager 772 so that it may provideexternal service routing information directly to the external servicesmanager. Name services manager 752 is also connected to secure databasemanager 744 to permit the name services manager 752 to access nameservices records stored within secure database 610.

[0921] External Services Manager 772 & Services Transport Layer 786

[0922] The External Services Manager 772 provides protocol supportcapabilities to interface to external service providers. Externalservices manager 772 may, for example, obtain external service routinginformation from name services manager 752, and then initiate contact toa particular external service (e.g., another VDE electronic appliance600, a financial clearinghouse, etc.) through communications manager776. External services manager 772 uses a service transport layer 786 tosupply communications protocols and other information necessary toprovide communications.

[0923] There are several important examples of the use of ExternalServices Manager 772. Some VDE objects may have some or all of theircontent stored at an Object Repository 728 on an electronic appliance600 other than the one operated by a user who has, or wishes to obtain.some usage rights to such VDE objects. In this case, External ServicesManager 772 may manage a connection to the electronic appliance 600where the VDE objects desired (or their content) is stored. In addition,file system 687 may be a network file system (e.g., Netware, LANtastic,NFS, etc.) that allows access to VDE objects using redirecter 684.Object switch 734 also supports this capability.

[0924] If External Services Manager 772 is used to access VDE objects,many different techniques are possible. For example, the VDE objects maybe formatted for use with the World Wide Web protocols (HTML, HTTP, andURL) by including relevant headers, content tags, host ID to URLconversion (e.g., using Name Services Manager 752) and an HTTP-awareinstance of Services Transport Layer 786.

[0925] In other examples, External Services Manager 772 may be used tolocate, connect to, and utilize remote event processing services; smartagent execution services (both to provide these services and locatethem); certification services for Public Keys; remote Name Services; andother remote functions either supported by ROS 602 RPCs (e.g.. haveRSIs), or using protocols supported by Services Transport Layer 786.

[0926] Outgoing Administrative Object Manager 754

[0927] Outgoing administrative object manager 754 receivesadministrative objects from object switch 734, object repository manager770 or other source for transmission to another VDE electronicappliance. Outgoing administrative object manager 754 takes care ofsending the outgoing object to its proper destination. Outgoingadministrative object manager 754 may obtain routing information fromname services manager 752, and may use communications service 776 tosend the object. Outgoing administrative object manager 754 typicallymaintains records (in concert with SPE 503) in secure database 610(e.g., shipping table 444) that reflect when objects have beensuccessfully transmitted, when an object should be transmitted, andother information related to transmission of objects.

[0928] Incoming Administrative Object Manager 756

[0929] Incoming administrative object manager 756 receivesadministrative objects from other VDE electronic appliances 600 viacommunications manager 776. It may route the object to object repositorymanager 770, object switch 734 or other destination. Incomingadministrative object manager 756 typically maintains records (inconcert with SPE 503) in secure database 610 (e.g., receiving table 446)that record which objects have been received, objects expected forreceipt, and other information related to received and/or expectedobjects.

[0930] Object Repository Manager 770

[0931] Object repository manager 770 is a form of database or filemanager. It manages the storage of VDE objects 300 in object repository728, in a database, or in the file system 687. Object repository manager770 may also provide the ability to browse and/or search informationrelated to objects (such as summaries of content, abstracts, reviewers'commentary, schedules, promotional materials, etc.), for example, byusing INFORMATION methods associated with VDE objects 300.

[0932] Object Submittal Manager 774

[0933] Object submittal manager 774 in the preferred embodiment providesan interface between an application 608 and object switch 734, and thusmay be considered in some respects part of API 682. For example, it mayallow a user application to create new VDE objects 300. It may alsoallow incoming/outgoing administrative object managers 756, 754 tocreate VDE objects 300 (administrative objects).

[0934]FIG. 12A shows how object submittal manager 774 may be used tocommunicate with a user of electronic appliance 600 to help to create anew VDE object 300. FIG. 12A shows that object creation may occur in twostages in the preferred embodiment: an object definition stage 1220, andan object creation stage 1230. The role of object submittal manager 774is indicated by the two different “user input” depictions (774(1),774(2)) shown in FIG. 12A.

[0935] In one of its roles or instances, object submittal manager 774provides a user interface 774 a that allows the user to create an objectconfiguration file 1240 specifying certain characteristics of a VDEobject 300 to be created. This user interface 774 a may, for example,allow the user to specify that she wants to create an object, allow theuser to designate the content the object will contain, and allow theuser to specify certain other aspects of the information to be containedwithin the object (e.g., rules and control information, identifyinginformation, etc.).

[0936] Part of the object definition task 1220 in the preferredembodiment may be to analyze the content or other information to beplaced within an object. Object definition user interface 774 a mayissue calls to object switch 734 to analyze “content” or otherinformation that is to be included within the object to be created inorder to define or organize the content into “atomic elements” specifiedby the user. As explained elsewhere herein, such “atomic element”organizations might, for example, break up the content into paragraphs,pages or other subdivisions specified by the user, and might be explicit(e.g., inserting a control character between each “atomic element”) orimplicit. Object switch 734 may receive static and dynamic content(e.g., by way of time independent stream interface 762 and real timestream interface 760), and is capable of accessing and retrieving storedcontent or other information stored within file system 687.

[0937] The result of object definition 1240 may be an objectconfiguration file 1240 specifying certain parameters relating to theobject to be created. Such parameters may include, for example, maptables, key management specifications, and event method parameters. Theobject construction stage 1230 may take the object configuration file1240 and the information or content to be included within the new objectas input, construct an object based on these inputs, and store theobject within object repository 728.

[0938] Object construction stage 1230 may use information in objectconfiguration file 1240 to assemble or modify a container. This processtypically involves communicating a series of events to SPE 503 to createone or more PERCs 808, public headers, private headers, and to encryptcontent, all for storage in the new object 300 (or within securedatabase 610 within records associated with the new object).

[0939] The object configuration file 1240 may be passed to containermanager 764 within object switch 734. Container manager 734 isresponsible for constructing an object 300 based on the objectconfiguration file 1240 and further user input. The user may interactwith the object construction 1230 through another instance 774(2) ofobject submittal manager 774. In this further user interaction providedby object submittal manager 774, the user may specify permissions, rulesand/or control information to be applied to or associated with the newobject 300. To specify permissions, rules and control information,object submittal manager 774 and/or container manager 764 within objectswitch 734 generally will, as mentioned above, need to issue calls toSPE 503 (e.g., through gateway 734) to cause the SPE to obtainappropriate information from secure database 610, generate appropriatedatabase items, and store the database items into the secure database610 and/or provide them in encrypted, protected form to the objectswitch for incorporation into the object. Such information provided bySPE 503 may include in addition to encrypted content or otherinformation, one or more PERCs 808, one or more method cores 1000′, oneor more load modules 1100, one or more data structures such as TDEs 1200and/or MDEs 1202, along with various key blocks, tags, public andprivate headers, and error correction information.

[0940] The container manager 764 may, in cooperation with SPE 503,construct an object container 302 based at least in part on parametersabout new object content or other information as specified by objectconfiguration file 1240. Container manager 764 may then insert into thecontainer 302 the content or other information (as encrypted by SPE 503)to be included in the new object. Container manager 764 may also insertappropriate permissions, rules and/or control information into thecontainer 302 (this permissions, rules and/or control information may bedefined at least in part by user interaction through object submittalmanager 774, and may be processed at least in part by SPE 503 to createsecure data control structures). Container manager 764 may then writethe new object to object repository 687, and the user or the electronicappliance may “register” the new object by including appropriateinformation within secure database 610.

[0941] Communications Subsystem 776

[0942] Communications subsystem 776, as discussed above, may be aconventional communications service that provides a network manager 780and a mail gateway manager 782. Mail filters 784 may be provided toautomatically route objects 300 and other VDE information to/from theoutside world. Communications subsystem 776 may support a real timecontent feed 684 from a cable, satellite or other telecommunicationslink.

[0943] Secure Processing Environment 503

[0944] As discussed above in connection with FIG. 12, each electronicappliance 600 in the preferred embodiment includes one or more SPEs 503and/or one or more HPEs 655. These secure processing environments eachprovide a protected execution space for performing tasks in a securemanner. They may fulfill service requests passed to them by ROS 602, andthey may themselves generate service requests to be satisfied by otherservices within ROS 602 or by services provided by another VDEelectronic appliance 600 or computer.

[0945] In the preferred embodiment, an SPE 503 is supported by thehardware resources of an SPU 500. An HPE 655 may be supported by generalpurpose processor resources and rely on software techniques forsecurity/protection. HPE 655 thus gives ROS 602 the capability ofassembling and executing certain component assemblies 690 on a generalpurpose CPU such as a microcomputer, minicomputer, mainframe computer orsupercomputer processor. In the preferred embodiment, the overallsoftware architecture of an SPE 503 may be the same as the softwarearchitecture of an HPE 655. An HPE 655 can “emulate” SPE 503 andassociated SPU 500, i.e., each may include services and resources neededto support an identical set of service requests from ROS 602 (althoughROS 602 may be restricted from sending to an HPE certain highly securetasks to be executed only within an SPU 500).

[0946] Some electronic appliance 600 configurations might include bothan SPE 503 and an HPE 655. For example, the HPE 655 could perform tasksthat need lesser (or no) security protections, and the SPE 503 couldperform all tasks that require a high degree of security. This abilityto provide serial or concurrent processing using multiple SPE and/or HPEarrangements provides additional flexibility, and may overcomelimitations imposed by limited resources that can practically orcost-effectively be provided within an SPU 500. The cooperation of anSPE 503 and an HPE 655 may, in a particular application, lead to a moreefficient and cost effective but nevertheless secure overall processingenvironment for supporting and providing the secure processing requiredby VDE 100. As one example, an HPE 655 could provide overall processingfor allowing a user to manipulate released object 300 ‘contents.’ butuse SPE 503 to access the secure object and release the information fromthe object.

[0947]FIG. 13 shows the software architecture of the preferredembodiment Secure Processing Environment (SPE) 503. This architecturemay also apply to the preferred embodiment Host Processing Environment(HPE) 655. “Protected Processing Environment” (“PPE”) 650 may refergenerally to SPE 503 and/or HPE 655. Hereinafter, unless contextindicates otherwise, references to any of “PPE 650,” “HPE 655” and “SPE503” may refer to each of them.

[0948] As shown in FIG. 13, SPE 503 (PPE 650) includes the followingservice managers/major functional blocks in the preferred embodiment:

[0949] Kernel/Dispatcher 552

[0950] Channel Services Manager 562

[0951] SPE RPC Manager 550

[0952] Time Base Manager 554

[0953] Encryption/Decryption Manager 556

[0954] Key and Tag Manager 558

[0955] Summary Services Manager 560

[0956] Authentication Manager/Service Communications Manager 564

[0957] Random Value Generator 565

[0958] Secure Database Manager 566

[0959] Other Services 592.

[0960] Each of the major functional blocks of PPE 650 is discussed indetail below.

[0961] I. SPE Kernel/Dispatcher 552

[0962] The Kernel/Dispatcher 552 provides an operating system “kernel”that runs on and manages the hardware resources of SPU 500. Thisoperating system “kernel” 552 provides a self-contained operating systemfor SPU 500; it is also a part of overall ROS 602 (which may includemultiple OS kernels, including one for each SPE and HPE ROS iscontrolling/managing). Kernel/dispatcher 552 provides SPU task andmemory management, supports internal SPU hardware interrupts, providescertain “low level services,” manages “DTD” data structures, and managesthe SPU bus interface unit 530 Kernel/dispatcher 552 also includes aload module execution manager 568 that can load programs into secureexecution space for execution by SPU 500.

[0963] In the preferred embodiment, kernel/dispatcher 552 may includethe following software/functional components:

[0964] load module execution manager 568

[0965] task manager 576

[0966] memory manager 578

[0967] virtual memory manager 580

[0968] “low level” services manager 582

[0969] internal interrupt handlers 584

[0970] BIU handler 586 (may not be present in HPE 655)

[0971] Service interrupt queues 588

[0972] DTD Interpreter 590.

[0973] At least parts of the kernel/dispatcher 552 are preferably storedin SPU firmware loaded into SPU ROM 532. An example of a memory map ofSPU ROM 532 is shown in FIG. 14A. This memory map shows the variouscomponents of kernel/dispatcher 552 (as well as the other SPE servicesshown in FIG. 13) residing in SPU ROM 532 a and/or EEPROM 532 b. TheFIG. 14B example of an NVRAM 534 b memory map shows the task manager 576and other information loaded into NVRAM.

[0974] One of the functions performed by kernel/dispatcher 552 is toreceive RPC calls from ROS RPC manager 732. As explained above, the ROSKernel RPC manager 732 can route RPC calls to the SPE 503 (via SPEDevice Driver 736 and its associated RSI 736 a) for action by the SPE.The SPE kernel/dispatcher 552 receives these calls and either handlesthem or passes them on to SPE RPC manager 550 for routing internally toSPE 503. SPE 503 based processes can also generate RPC requests. Some ofthese requests can be processed internally by the SPE 503. If they arenot internally serviceable, they may be passed out of the SPE 503through SPE kernel/dispatcher 552 to ROS RPC manager 732 for routing toservices external to SPE 503.

[0975] A. Kernel/Dispatcher Task Management

[0976] Kernel/dispatcher task manager 576 schedules and oversees tasksexecuting within SPE 503 (PPE 650). SPE 503 supports many types oftasks. A “channel” (a special type of task that controls execution ofcomponent assemblies 690 in the preferred embodiment) is treated by taskmanager 576 as one type of task. Tasks are submitted to the task manager576 for execution. Task manager 576 in turn ensures that the SPE 503/SPU500 resources necessary to execute the tasks are made available, andthen arranges for the SPU microprocessor 520 to execute the task.

[0977] Any call to kernel/dispatcher 552 gives the kernel an opportunityto take control of SPE 503 and to change the task or tasks that arecurrently executing. Thus, in the preferred embodiment kernel dispatchertask manager 576 may (in conjunction with virtual memory manager 580and/or memory manager 578) “swap out” of the execution space any or allof the tasks that are currently active, and “swap in” additional ordifferent tasks.

[0978] SPE tasking managed by task manager 576 may be either “singletasking” (meaning that only one task may be active at a time) or“multi-tasking” (meaning that multiple tasks may be active at once). SPE503 may support single tasking or multi-tasking in the preferredembodiment. For example, “high end” implementations of SPE 503 (e.g., inserver devices) should preferably include multi-tasking with “preemptivescheduling.” Desktop applications may be able to use a simpler SPE 503,although they may still require concurrent execution of several tasks.Set top applications may be able to use a relatively simpleimplementation of SPE 503, supporting execution of only one task at atime. For example, a typical set top implementation of SPU 500 mayperform simple metering, budgeting and billing using subsets of VDEmethods combined into single “aggregate” load modules to permit thevarious methods to execute in a single tasking environment. However, anexecution environment that supports only single tasking may limit usewith more complex control structures. Such single tasking versions ofSPE 503 trade flexibility in the number and types of metering andbudgeting operations for smaller run time RAM size requirements. Suchimplementations of SPE 503 may (depending upon memory limitations) alsobe limited to metering a single object 300 at a time. Of course,variations or combinations are possible to increase capabilities beyonda simple single tasking environment without incurring the additionalcost required to support “full multitasking.”

[0979] In the preferred embodiment, each task in SPE 503 is representedby a “swap block,” which may be considered a “task” in a traditionalmultitasking architecture. A “swap block” in the preferred embodiment isa bookkeeping mechanism used by task manager 576 to keep track of tasksand subtasks. It corresponds to a chunk of code and associatedreferences that “fits” within the secure execution environment providedby SPU 500. In the preferred embodiment, it contains a list ofreferences to shared data elements (e.g., load modules 1100 and UDEs1200), private data elements (e.g., method data and local stack), andswapped process “context” information (e.g., the register set for theprocess when it is not processing). FIG. 14C shows an example of asnapshot of SPU RAM 532 storing several examples of “swap blocks” for anumber of different tasks/methods such as a “channel” task, a “control”task, an “event” task, a “meter” task, a “budget” task, and a “billing”task. Depending on the size of SPU RAM 532, “swap blocks” may be swappedout of RAM and stored temporarily on secondary storage 652 until theirexecution can be continued. Thus, SPE 503 operating in a multi-taskingmode may have one or more tasks “sleeping.” In the simplest form, thisinvolves an active task that is currently processing, and another task(e.g., a control task under which the active task may be running) thatis “sleeping” and is “swapped out” of active execution space.Kernel/dispatcher 522 may swap out tasks at any time.

[0980] Task manager 576 may use Memory Manager 578 to help it performthis swapping operation. Tasks may be swapped out of the secureexecution space by reading appropriate information from RAM and otherstorage internal to SPU 500, for example, and writing a “swap block” tosecondary storage 652. Kernel 552 may swap a task back into the secureexecution space by reading the swap block from secondary storage 652 andwriting the appropriate information back into SPU RAM 532. Becausesecondary storage 652 is not secure, SPE 503 must encrypt andcryptographically seal (e.g., using a one-way hash function initializedwith a secret value known only inside the SPU 500) each swap blockbefore it writes it to secondary storage. The SPE 503 must decrypt andverify the cryptographic seal for each swap block read from secondarystorage 652 before the swap block can be returned to the secureexecution space for further execution.

[0981] Loading a “swap block” into SPU memory may require one or more“paging operations” to possibly first save, and then flush, any “dirtypages” (i.e., pages changed by SPE 503) associated with the previouslyloaded swap blocks, and to load all required pages for the new swapblock context.

[0982] Kernel/dispatcher 522 preferably manages the “swap blocks” usingservice interrupt queues 588. These service interrupt queues 588 allowkernel/dispatcher 552 to track tasks (swap blocks) and their status(running, “swapped out,” or “asleep”). The kernel/dispatcher 552 in thepreferred embodiment may maintain the following service interrupt queues588 to help it manage the “swap blocks”:

[0983] RUN queue

[0984] SWAP queue

[0985] SLEEP queue.

[0986] Those tasks that are completely loaded in the execution space andare waiting for and or using execution cycles from microprocessor 502are in the RUN queue. Those tasks that are “swapped” out (e.g., becausethey are waiting for other swappable components to be loaded) arereferenced in the SWAP queue. Those tasks that are “asleep” (e.g.,because they are “blocked” on some resource other than processor cyclesor are not needed at the moment) are referenced in the SLEEP queue.Kernel/dispatcher task manager 576 may, for example, transition tasksbetween the RUN and SWAP queues based upon a “round-robin” schedulingalgorithm that selects the next task waiting for service, swaps in anypieces that need to be paged in, and executes the task.Kernel/dispatcher 552 task manager 576 may transition tasks between theSLEEP queue and the “awake” (i.e., RUN or SWAP) queues as needed.

[0987] When two or more tasks try to write to the same data structure ina multi-tasking environment, a situation exists that may result in“deadly embrace” or “task starvation.” A “multi-threaded” taskingarrangement may be used to prevent “deadly embrace” or “task starvation”from happening. The preferred embodiment kernel/dispatcher 552 maysupport “single threaded” or “multi-threaded” tasking.

[0988] In single threaded applications, the kernel/dispatcher 552“locks” individual data structures as they are loaded. Once locked, noother SPE 503 task may load them and will “block” waiting for the datastructure to become available. Using a single threaded SPE 503 may, as apractical matter, limit the ability of outside vendors to create loadmodules 1100 since there can be no assurance that they will not cause a“deadly embrace” with other VDE processes about which outside vendorsmay know little or nothing. Moreover. the context swapping of apartially updated record might destroy the integrity of the system,permit unmetered use, and/or lead to deadlock. In addition, such“locking” imposes a potentially indeterminate delay into a typicallytime critical process, may limit SPE 503 throughput, and may increaseoverhead.

[0989] This issue notwithstanding, there are other significantprocessing issues related to building single-threaded versions of SPE503 that may limit its usefulness or capabilities under somecircumstances. For example, multiple concurrently executing tasks maynot be able to process using the same often-needed data structure in asingle-threaded SPE 503. This may effectively limit the number ofconcurrent tasks to one. Additionally, single-threadedness may eliminatethe capability of producing accurate summary budgets based on a numberof concurrent tasks since multiple concurrent tasks may not be able toeffectively share the same summary budget data structure.Single-threadedness may also eliminate the capability to support auditprocessing concurrently with other processing. For example, real-timefeed processing might have to be shut down in order to audit budgets andmeters associated with the monitoring process.

[0990] One way to provide a more workable “ingle-threaded” capability isfor kernel/dispatcher 552 to use virtual page handling algorithms totrack “dirty pages” as data areas are written to. The “dirty pages” canbe swapped in and out with the task swap block as part of local dataassociated with the swap block. When a task exits, the “dirty pages” canbe merged with the current data structure (possibly updated by anothertask for SPU 500) using a three-way merge algorithm (i.e., merging theoriginal data structure, the current data structure, and the “dirtypages” to form a new current data structure). During the update process,the data structure can be locked as the pages are compared and swapped.Even though this virtual paging solution might be workable for allowingsingle threading in some applications, the vendor limitations mentionedabove may limit the use of such single threaded implementations in somecases to dedicated hardware. Any implementation that supports multipleusers (e.g., “smart home” set tops, many desk tops and certain PDAapplications, etc.) may hit limitations of a single threaded device incertain circumstances.

[0991] It is preferable when these limitations are unacceptable to use afill “multi-threaded” data structure write capabilities. For example, atype of “two-phase commit” processing of the type used by databasevendors may be used to allow data structure sharing between processes.To implement this “two-phase commit” process, each swap block maycontain page addresses for additional memory blocks that will be used tostore changed information. A change page is a local copy of a piece of adata element that has been written by an SPE process. The changedpage(s) references associated with a specific data structure are storedlocally to the swap block in the preferred embodiment.

[0992] For example, SPE 503 may support two (change pages) per datastructure. This limit is easily alterable by changing the size of theswap block structure and allowing the update algorithm to process all ofthe changed pages. The “commit” process can be invoked when a swap blockthat references changed pages is about to be discarded. The commitprocess takes the original data element that was originally loaded(e.g., UDE₀), the current data element (e.g., UDE_(n)) and the changedpages, and merges them to create a new copy of the data element (e.g.,UDE_(n+1)). Differences can be resolved by the DTD interpreter 590 usinga DTD for the data element. The original data element is discarded(e.g., as determined by its DTD use count) if no other swap blockreferences it.

[0993] B. Kernel/Dispatcher Memory Management

[0994] Memory manager 578 and virtual memory manager 580 in thepreferred embodiment manage ROM 532 and RAM 534 memory within SPU 500 inthe preferred embodiment. Virtual memory manager 580 provides a fully“virtual” memory system to increase the amount of “virtual” RAMavailable in the SPE secure execution space beyond the amount ofphysical RAM 534 a provided by SPU 500. Memory manager 578 manages thememory in the secure execution space, controlling how it is accessed,allocated and deallocated. SPU MMU 540, if present, supports virtualmemory manager 580 and memory manager 578 in the preferred embodiment.In some “minimal” configurations of SPU 500 there may be no virtualmemory capability and all memory management functions will be handled bymemory manager 578. Memory management can also be used to help enforcethe security provided by SPE 503. In some classes of SPUs 500, forexample, the kernel memory manager 578 may use hardware memorymanagement unit (MMU) 540 to provide page level protection within theSPU 500. Such a hardware-based memory management system provides aneffective mechanism for protecting VDE component assemblies 690 fromcompromise by “rogue” load modules.

[0995] In addition, memory management provided by memory manager 578operating at least in part based on hardware-based MMU 540 may securelyimplement and enforce a memory architecture providing multipleprotection domains. In such an architecture, memory is divided into aplurality of domains that are largely isolated from each other and shareonly specific memory areas under the control of the memory manager 578.An executing process cannot access memory outside its domain and canonly communicate with other processes through services provided by andmediated by privileged kernel/dispatcher software 552 within the SPU500. Such an architecture is more secure if it is enforced at least inpart by hardware within MMU 540 that cannot be modified by anysoftware-based process executing within SPU 500.

[0996] In the preferred embodiment, access to services implemented inthe ROM 532 and to physical resources such as NVRAM 534 b and RTC 528are mediated by the combination of privileged kernel/dispatcher software552 and hardware within MMU 540. ROM 532 and RTC 528 requests areprivileged in order to protect access to critical system componentroutines (e.g., RTC 528).

[0997] Memory manager 578 is responsible for allocating and deallocatingmemory; supervising sharing of memory resources between processes; andenforcing memory access/use restriction. The SPE kernel/dispatchermemory manager 578 typically initially allocates all memory to kernel552, and may be configured to permit only process-level access to pagesas they are loaded by a specific process. In one example SPE operatingsystem configuration, memory manager 578 allocates memory using asimplified allocation mechanism. A list of each memory page accessiblein SPE 503 may be represented using a bit map allocation vector, forexample. In a memory block, a group of contiguous memory pages may startat a specific page number. The size of the block is measured by thenumber of memory pages it spans. Memory allocation may be recorded bysetting/clearing the appropriate bits in the allocation vector.

[0998] To assist in memory management functions, a “dope vector” may beprepended to a memory block. The “dope vector” may contain informationallowing memory manager 578 to manage that memory block. In its simplestform, a memory block may be structured as a “dope vector” followed bythe actual memory area of the block. This “dope vector” may include theblock number, support for dynamic paging of data elements, and a markerto detect memory overwrites. Memory manager 578 may track memory blocksby their block number and convert the block number to an address beforeuse. All accesses to the memory area can be automatically offset by thesize of the “dope vector” during conversion from a block memory to aphysical address. “Dope vectors” can also be used by virtual memorymanager 580 to help manage virtual memory.

[0999] The ROM 532 memory management task performed by memory manager578 is relatively simple in the preferred embodiment. All ROM 532 pagesmay be flagged as “read only” and as “non-pagable.” EEPROM 532B memorymanagement may be slightly more complex since the “burn count” for eachEEPROM page may need to be retained. SPU EEPROM 532B may need to beprotected from all uncontrolled writes to conserve the limited writablelifetime of certain types of this memory. Furthermore, EEPROM pages mayin some cases not be the same size as memory management address pages.

[1000] SPU NVRAM 534 b is preferably battery backed RAM that has a fewaccess restrictions. Memory manager 578 can ensure control structuresthat must be located in NVRAM 534 b are not relocated during “garbagecollection” processes. As discussed above, memory manager 578 (and MMU540 if present) may protect NVRAM 534 b and RAM 534 a at a page level toprevent tampering by other processes.

[1001] Virtual memory manager 580 provides paging for programs and databetween SPU external memory and SPU internal RAM 534 a. It is likelythat data structures and executable processes will exceed the limits ofany SPU 500 internal memory. For example, PERCs 808 and otherfundamental control structures may be fairly large, and “bit map meters”may be, or become, very large. This eventuality may be addressed in twoways:

[1002] (1) subdividing load modules 1100; and

[1003] (2) supporting virtual paging.

[1004] Load modules 1100 can be “subdivided” in that in many instancesthey can be broken up into separate components only a subset of whichmust be loaded for execution. Load modules 1100 are the smallest pagableexecutable element in this example. Such load modules 1100 can be brokenup into separate components (e.g., executable code and plural datadescription blocks), only one of which must be loaded for simple loadmodules to execute. This structure permits a load module 1100 toinitially load only the executable code and to load the data descriptionblocks into the other system pages on a demand basis. Many load modules1100 that have executable sections that are too large to fit into SPU500 can be restructured into two or more smaller independent loadmodules. Large load modules may be manually “split” into multiple loadmodules that are “chained” together using explicit load modulereferences.

[1005] Although “demand paging” can be used to relax some of theserestrictions, the preferred embodiment uses virtual paging to managelarge data structures and executables. Virtual Memory Manager 580“swaps” information (e.g., executable code and/or data structures) intoand out of SPU RANI 534 a, and provides other related virtual memorymanagement services to allow a full virtual memory managementcapability. Virtual memory management may be important to allow limitedresource SPU 500 configurations to execute large and/or multiple tasks.

[1006] C. SPE Load Module Execution Manager 568

[1007] The SPE (HPE) load module execution manager (“LMEM”) 568 loadsexecutables into the memory managed by memory manager 578 and executesthem. LMEM 568 provides mechanisms for tracking load modules that arecurrently loaded inside the protected execution environment. LMEM 568also provides access to basic load modules and code fragments storedwithin, and thus always available to, SPE 503. LMEM 568 may be called,for example, by load modules 1100 that want to execute other loadmodules.

[1008] In the preferred embodiment, the load module execution manager568 includes a load module executor (“program loader”) 570, one or moreinternal load modules 572, and library routines 574. Load moduleexecutor 570 loads executables into memory (e.g., after receiving amemory allocation from memory manager 578) for execution. Internal loadmodule library 572 may provide a set of commonly used basic load modules1100 (stored in ROM 532 or NVRAM 534 b, for example). Library routines574 may provide a set of commonly used code fragments/routines (e.g.,bootstrap routines) for execution by SPE 503.

[1009] Library routines 574 may provide a standard set of libraryfunctions in ROM 532. A standard list of such library functions alongwith their entry points and parameters may be used. Load modules 1100may call these routines (e.g., using an interrupt reserved for thispurpose). Library calls may reduce the size of load modules by movingcommonly used code into a central location and permitting a higherdegree of code reuse. All load modules 1100 for use by SPE 503 arepreferably referenced by a load module execution manager 568 thatmaintains and scans a list of available load modules and selects theappropriate load module for execution. If the load module is not presentwithin SPE 503, the task is “slept” and LMEM 568 may request that theload module 1100 be loaded from secondary storage 562. This request maybe in the form of an RPC call to secure database manager 566 to retrievethe load module and associated data structures, and a call toencrypt/decrypt manager 556 to decrypt the load module before storing itin memory allocated by memory manager 578.

[1010] In somewhat more detail, the preferred embodiment executes a loadmodule 1100 by passing the load module execution manager 568 the name(e.g., VDE ID) of the desired load module 1100. LMEM 568 first searchesthe list of “in memory” and “built-in” load modules 572. If it cannotfind the desired load module 1100 in the list, it requests a copy fromthe secure database 610 by issuing an RPC request that may be handled byROS secure database manager 744 shown in FIG. 12. Load module executionmanager 568 may then request memory manager 578 to allocate a memorypage to store the load module 1100. The load module execution manager568 may copy the load module into that memory page, and queue the pagefor decryption and security checks by encrypt/decrypt manager 556 andkey and tag manager 558. Once the page is decrypted and checked, theload module execution manager 568 checks the validation tag and insertsthe load module into the list of paged in modules and returns the pageaddress to the caller. The caller may then call the load module 1100directly or allow the load module execution module 570 to make the callfor it.

[1011]FIG. 15a shows a detailed example of a possible format for achannel header 596 and a channel 594 containing channel detail records594(1), 594(2), . . . 594(N). Channel header 596 may include a channelID field 597(1), a user ID field 597(2), an object ID field 597(3), afield containing a reference or other identification to a “right” (i.e.,a collection of events supported by methods referenced in a PERC 808and/or “user rights table” 464) 597(4), an event queue 597(5), and oneor more fields 598 that cross-reference particular event codes withchannel detail records (“CDRs”). Channel header 596 may also include a“jump” or reference table 599 that permits addressing of elements withinan associated component assembly or assemblies 690. Each CDR 594(1), . .. 594(N) corresponds to a specific event (event code) to which channel594 may respond. In the preferred embodiment, these CDRs may includeexplicitly and/or by reference each method core 1000′ (or fragmentthereof), load module 1100 and data structure(s), (e.g., URT, UDE 1200and/or MDE 1202) needed to process the corresponding event. In thepreferred embodiment, one or more of the CDRs (e.g., 594(1)) mayreference a control method and a URT 464 as a data structure.

[1012]FIG. 15b shows an example of program control steps performed bySPE 503 to “open” a channel 594 in the preferred embodiment. In thepreferred embodiment, a channel 594 provides event processing for aparticular VDE object 300, a particular authorized user, and aparticular “right” (i.e., type of event). These three parameters may bepassed to SPE 503. Part of SPE kernel/dispatcher 552 executing within a“channel 0” constructed by low level services 582 during a “bootstrap”routine may respond initially to this “open channel” event by allocatingan available channel supported by the processing resources of SPE 503(block 1125). This “channel 0” “open channel” task may then issue aseries of requests to secure database manager 566 to obtain the“blueprint” for constructing one or more component assemblies 690 to beassociated with channel 594 (block 1127). In the preferred embodiment,this “blueprint” may comprise a PERC 808 and/or URT 464. In may beobtained by using the “Object, User, Right” parameters passed to the“open channel” routine to “chain” together object registration table 460records, user/object table 462 records, URT 464 records, and PERC 808records. This “open channel” task may preferably place calls to key andtag manager 558 to validate and correlate the tags associated with thesevarious records to ensure that they are authentic and match. Thepreferred embodiment process then may write appropriate information tochannel header 596 (block 1129). Such information may include, forexample, User ID, Object ID, and a reference to the “right” that thechannel will process. The preferred embodiment process may next use the“blueprint” to access (e.g, the secure database manager 566 and/or fromload module execution manager library(ies) 568) the appropriate “controlmethod” that may be used to, in effect, supervise execution of all ofthe other methods 1000 within the channel 594 (block 1131). The processmay next “bind” this control method to the channel (block 1133), whichstep may include binding information from a URT 464 into the channel asa data structure for the control method. The process may then pass an“initialization” event into channel 594 (block 1135). This“initialization” event may be created by the channel services manager562, the process that issued the original call requesting a servicebeing fulfilled by the channel being built, or the control method justbound to the channel could itself possibly generate an initializationevent which it would in effect pass to itself.

[1013] In response to this “initialization” event, the control methodmay construct the channel detail records 594(1), . . . 594(N) used tohandle further events other than the “initialization” event. The controlmethod executing “within” the channel may access the various componentsit needs to construct associated component assemblies 690 based on the“blueprint” accessed at step 1127 (block 1137). Each of these componentsis bound to the channel 594 (block 1139) by constructing an associatedchannel detail record specifying the method core(s) 1000′, loadmodule(s) 1100, and associated data structure(s) (e.g., UDE(s) 1200and/or MDE(s) 1202) needed to respond to the event. The number ofchannel detail records will depend on the number of events that can beserviced by the “right,” as specified by the “blueprint” (i.e., URT464). During this process, the control method will construct “swapblocks” to, in effect, set up all required tasks and obtain necessarymemory allocations from kernel 562. The control method will, asnecessary, issue calls to secure database manager 566 to retrievenecessary components from secure database 610, issue calls toencrypt/decrypt manager 556 to decrypt retrieved encrypted information,and issue calls to key and tag manager 558 to ensure that all retrievedcomponents are validated. Each of the various component assemblies 690so constructed are “bound” to the channel through the channel headerevent code/pointer records 598 and by constructing appropriate swapblocks referenced by channel detail records 594(1), . . . 594(N). Whenthis process is complete, the channel 594 has been completelyconstructed and is ready to respond to further events. As a last step,the FIG. 15b process may, if desired, deallocate the “initialization”event task in order to free up resources.

[1014] Once a channel 594 has been constructed in this fashion, it willrespond to events as they arrive. Channel services manager 562 isresponsible for dispatching events to channel 594. Each time a new eventarrives (e.g., via an RPC call), channel services manager 562 examinesthe event to determine whether a channel already exists that is capableof processing it. If a channel does exist, then the channel servicesmanager 562 passes the event to that channel. To process the event, itmay be necessary for task manager 576 to “swap in” certain “swappableblocks” defined by the channel detail records as active tasks. In thisway, executable component assemblies 690 formed during the channel openprocess shown in FIG. 15b are placed into active secure execution space,the particular component assembly that is activated being selected inresponse to the received event code. The activated task will thenperform its desired function in response to the event.

[1015] To destroy a channel, the various swap blocks defined by thechannel detail records are destroyed, the identification information inthe channel header 596 is wiped clean, and the channel is made availablefor re-allocation by the “channel 0” “open channel” task.

[1016] D. SPE Interrupt Handlers 584

[1017] As shown FIG. 13, kernel/dispatcher 552 also provides internalinterrupt handler(s) 584. These help to manage the resources of SPU 500.SPU 500 preferably executes in either “interrupt” or “polling” mode forall significant components. In polling mode, kernel/dispatcher 552 maypoll each of the sections/circuits within SPU 500 and emulate aninterrupt for them. The following interrupts are preferably supported bySPU 500 in the preferred embodiment:

[1018] “tick” of RTC 528

[1019] interrupt from bus interface 530

[1020] power fail interrupt

[1021] watchdog timer interrupt

[1022] interrupt from encrypt/decrypt engine 522

[1023] memory interrupt (e.g., from MMU 540).

[1024] When an interrupt occurs, an interrupt controller withinmicroprocessor 520 may cause the microprocessor to begin executing anappropriate interrupt handler. An interrupt handler is a piece ofsoftware/firmware provided by kernel/dispatcher 552 that allowsmicroprocessor 520 to perform particular functions upon the occurrenceof an interrupt. The interrupts may be “vectored” so that differentinterrupt sources may effectively cause different interrupt handlers tobe executed.

[1025] A “timer tick” interrupt is generated when the real-time RTC 528“pulses.” The timer tick interrupt is processed by a timer tickinterrupt handler to calculate internal device date/time and to generatetimer events for channel processing.

[1026] The bus interface unit 530 may generate a series of interrupts.In the preferred embodiment, bus interface 530, modeled after a USART,generates interrupts for various conditions (e.g., “receive bufferfull,” “transmitter buffer empty,” and “status word change”).Kernel/dispatcher 552 services the transmitter buffer empty interrupt bysending the next character from the transmit queue to the bus interface530. Kernel/dispatcher interrupt handler 584 may service the receivedbuffer full interrupt by reading a character, appending it to thecurrent buffer, and processing the buffer based on the state of theservice engine for the bus interface 530. Kernel/dispatcher 552preferably processes a status word change interrupt and addresses theappropriate send/receive buffers accordingly.

[1027] SPU 500 generates a power fail interrupt when it detects animminent power fail condition. This may require immediate action toprevent loss of information. For example, in the preferred embodiment, apower fail interrupt moves all recently written information (i.e.,“dirty pages”) into non-volatile NVRAM 534 b, marks all swap blocks as“swapped out,” and sets the appropriate power fail flag to facilitaterecovery processing. Kernel/dispatcher 552 may then periodically pollthe “power fail bit” in a status word until the data is cleared or thepower is removed completely.

[1028] SPU 500 in the example includes a conventional watchdog timerthat generates watchdog timer interrupts on a regular basis. A watchdogtimer interrupt handler performs internal device checks to ensure thattampering is not occurring. The internal clocks of the watchdog timerand RTC 528 are compared to ensure SPU 500 is not being paused orprobed, and other internal checks on the operation of SPU 500 are madeto detect tampering.

[1029] The encryption/decryption engine 522 generates an interrupt whena block of data has been processed. The kernel interrupt handler 584adjusts the processing status of the block being encrypted or decrypted,and passes the block to the next stage of processing. The next blockscheduled for the encryption service then has its key moved into theencrypt/decrypt engine 522, and the next cryptographic process started.

[1030] A memory management unit 540 interrupt is generated when a taskattempts to access memory outside the areas assigned to it. A memorymanagement interrupt handler traps the request, and takes the necessaryaction (e.g., by initiating a control transfer to memory manager 578and/or virtual memory manager 580). Generally, the task will be failed,a page fault exception will be generated, or appropriate virtual memorypage(s) will be paged in.

[1031] E. Kernel/Dispatcher Low Level Services 582

[1032] Low level services 582 in the preferred embodiment provide “lowlevel” functions. These functions in the preferred embodiment mayinclude, for example, power-on initialization, device POST, and failurerecovery routines. Low level services 582 may also in the preferredembodiment provide (either by themselves or in combination withauthentication manager/service communications manager 564) downloadresponse-challenge and authentication communication protocols, and mayprovide for certain low level management of SPU 500 memory devices suchas EEPROM and FLASH memory (either alone or in combination with memorymanager 578 and/or virtual memory manager 580).

[1033] F. Kernel/Dispatcher BIU Handler 586

[1034] BIU handler 586 in the preferred embodiment manages the businterface unit 530 (if present). It may, for example, maintain read andwrite buffers for the BIU 530, provide BIU startup initialization, etc

[1035] G. Kernel/Dispatcher DTD Interpreter 590

[1036] DTD interpreter 590 in the preferred embodiment handles dataformatting issues. For example, the DTD interpreter 590 mayautomatically open data structures such as LDEs 1200 based on formattinginstructions contained within DTDs.

[1037] The SPE kernel/dispatcher 552 discussed above supports all of theother services provided by SPE 503. Those other services are discussedbelow.

[1038] II. SPU Channel Services Manager 562

[1039] “Channels” are the basic task processing mechanism of SPE 503(HPE 655) in the preferred embodiment. ROS 602 provides an event-driveninterface for “methods.” A “channel” allows component assemblies 690 toservice events. A “channel” is a conduit for passing “events” fromservices supported by SPE 503 (HPE 655) to the various methods and loadmodules that have been specified to process these events, and alsosupports the assembly of component assemblies 690 and interactionbetween component assemblies. In more detail, “channel” 594 is a datastructure maintained by channel manager 593 that “binds” together one ormore load modules 1100 and data structures (e.g., UDEs 1200 and/or MDEs1202) into a component assembly 690. Channel services manager 562 causesload module execution manager 569 to load the component assembly 690 forexecution, and may also be responsible for passing events into thechannel 594 for response by a component assembly 690. In the preferredembodiment, event processing is handled as a message to the channelservice manager 562.

[1040]FIG. 15 is a diagram showing how the preferred embodiment channelservices manager 562 constructs a “channel” 594, and also shows therelationship between the channel and component assemblies 690. Briefly,the SPE channel manager 562 establishes a “channel” 594 and anassociated “channel header” 596. The channel 594 and its header 596comprise a data structure that “binds” or references elements of one ormore component assemblies 690. Thus, the channel 594 is the mechanism inthe preferred embodiment that collects together or assembles theelements shown in FIG. 11E into a component assembly 690 that may beused for event processing.

[1041] The channel 594 is set up by the channel services manager 562 inresponse to the occurrence of an event. Once the channel is created, thechannel services manager 562 may issue function calls to load moduleexecution manager 568 based on the channel 594. The load moduleexecution manager 568 loads the load modules 1100 referenced by achannel 594, and requests execution services by the kernel/dispatchertask manager 576. The kernel/dispatcher 552 treats the event processingrequest as a task, and executes it by executing the code within the loadmodules 1100 referenced by the channel.

[1042] The channel services manager 562 may be passed an identificationof the event (e.g., the “event code”). The channel services manager 562parses one or more method cores 1000′ that are part of the componentassembly(ies) 690 the channel services manager is to assemble. Itperforms this parsing to determine which method(s) and data structure(s)are invoked by the type of event. Channel manager 562 then issues calls(e.g., to secure database manager 566) to obtain the methods and datastructure(s) needed to build the component assembly 690. Thesecalled-for method(s) and data structure(s) (e.g., load modules 1100,UDEs 1200 and/or MDEs 1202) are each decrypted using encrypt/decryptmanager 556 (if necessary), and are then each validated using key andtag manager 558. Channel manager 562 constructs any necessary “jumptable” references to, in effect, “link” or “bind” the elements into asingle cohesive executable so the load module(s) can reference datastructures and any other load module(s) in the component assembly.Channel manager 562 may then issue calls to LMEM 568 to load theexecutable as an active task.

[1043]FIG. 15 shows that a channel 594 may reference another channel. Anarbitrary number of channels 594 may be created by channel manager 594to interact with one another.

[1044] “Channel header” 596 in the preferred embodiment is (orreferences) the data structure(s) and associated control program(s) thatqueues events from channel event sources, processes these events, andreleases the appropriate tasks specified in the “channel detail record”for processing. A “channel detail record” in the preferred embodimentlinks an event to a “swap block” (i.e. task) associated with that event.The “swap block” may reference one or more load modules 1100, UDEs 1200and private data areas required to properly process the event. One swapblock and a corresponding channel detail item is created for eachdifferent event the channel can respond to.

[1045] In the preferred embodiment, Channel Services Manager 562 maysupport the following (internal) calls to support the creation andmaintenance of channels 562: Call Name Source Description “Write Event”Write Writes an event to the channel for response by the channel. TheWrite Event call thus permit the caller to insert an event into theevent queue associated with the channel. The event will be processed inturn by the channel 594. “Bind Item” Ioctl Binds an item to a channelwith the appropriate processing algorithm. The Bind Item call permitsthe caller to bind a VDE item ID to a channel (e.g., to create one ormore swap blocks associated with a channel). This call may manipulatethe contents of individual swap blocks. “Unbind Item” Ioctl Unbinds anitem from a channel with the appropriate processing algorithm. TheUnbind Item call permits the caller to break the binding of an item to aswap block. This call may manipulate the contents of individual swapblocks.

[1046] SPE RPC Manager 550

[1047] As described in connection with FIG. 12, the architecture of ROS602 is based on remote procedure calls in the preferred embodiment. ROS602 includes an RPC Manager 732 that passes RPC calls between serviceseach of which present an RPC service interface (“RSI”) to the RPCmanager In the preferred embodiment, SPE 503 (HPE 655) is also builtaround the same RPC concept. The SPE 503 (HPE 655) may include a numberof internal modular service providers each presenting an RSI to an RPCmanager 550 internal to the SPE (HPE). These internal service providersmay communicate with each other and/or with ROS RPC manager 732 (andthus, with any other service provided by ROS 602 and with externalservices), using RPC service requests

[1048] RPC manager 550 within SPE 503 (HPE 655) is not the same as RPCmanager 732 shown in FIG. 12, but it performs a similar function withinthe SPE (HPE): it receives RPC requests and passes them to the RSIpresented by the service that is to fulfill the request. In thepreferred embodiment, requests are passed between ROS RPC manager 732and the outside world (i.e., SPE device driver 736) via the SPE (HPE)Kernel/Dispatcher 552. Kernel/Dispatcher 552 may be able to servicecertain RPC requests itself, but in general it passes received requeststo RPC manager 550 for routing to the appropriate service internal tothe SPE (HPE). In an alternate embodiment, requests may be passeddirectly between the HPE, SPE, API, Notification interface, and otherexternal services instead of routing them through the ROS RPC manager732. The decision on which embodiment to use is part of the scalabilityof the system; some embodiments are more efficient than others undervarious traffic loads and system configurations. Responses by theservices (and additional service requests they may themselves generate)are provided to RPC Manager 550 for routing to other service(s) internalor external to SPE 503 (HPE 655).

[1049] SPE RPC Manager 550 and its integrated service manager uses twotables to dispatch remote procedure calls: an RPC services table, and anoptional RPC dispatch table. The RPC services table describes whererequests for specific services are to be routed for processing. In thepreferred embodiment, this table is constructed in SPU RAM 534 a orNVRAM 534 b, and lists each RPC service “registered” within SPU 500.Each row of the RPC services table contains a service ID, its locationand address, and a control byte. In simple implementations, the controlbyte indicates only that the service is provided internally orexternally. In more complex implementations, the control byte canindicate an instance of the service (e.g., each service may havemultiple “instances” in a multi-tasking environment). ROS RPC manager732 and SPE 503 may have symmetric copies of the RPC services table inthe preferred embodiment. If an RPC service is not found in the RPCservices table, SPE 503 may either reject it or pass it to ROS RPCmanager 732 for service.

[1050] The SPE RPC manager 550 accepts the request from the RPC servicetable and processes that request in accordance with the internalpriorities associated with the specific service In SPE 503, the RPCservice table is extended by an RPC dispatch table. The preferredembodiment RPC dispatch table is organized as a list of Load Modulereferences for each RPC service supported internally by SPE 503 Each rowin the table contains a load module ID that services the call, a controlbyte that indicates whether the call can be made from an externalcaller, and whether the load module needed to service the call ispermanently resident in SPU 500. The RPC dispatch table may beconstructed in SPU ROM 532 (or EEPROM) when SPU firmware 508 is loadedinto the SPU 500. If the RPC dispatch table is in EEPROM, it flexiblyallows for updates to the services without load module location andversion control issues.

[1051] In the preferred embodiment, SPE RPC manager 550 first referencesa service request against the RPC service table to determine thelocation of the service manager that may service the request. The RPCmanager 550 then routes the service request to the appropriate servicemanager for action. Service requests are handled by the service managerwithin the SPE 503 using the RPC dispatch table to dispatch the request.Once the RPC manager 550 locates the service reference in the RPCdispatch table, the load module that services the request is called andloaded using the load module execution manager 568. The load moduleexecution manager 568 passes control to the requested load module afterperforming all required context configuration, or if necessary may firstissue a request to load it from the external management files 610

[1052] SPU Time Base Manager 554

[1053] The time base manager 554 supports calls that relate to the realtime clock (“RTC”) 528. In the preferred embodiment, the time basemanager 554 is always loaded and ready to respond to time basedrequests.

[1054] The table below lists examples of basic calls that may besupported by the time base manager 554: Call Name DescriptionIndependent requests Get Time Returns the time (local, GMT, or ticks).Set time Sets the time in the RTC 528. Access to this command may berestricted to a VDE administrator. Adjust time Changes the time in theRTC 528. Access to this command may be restricted to a VDEadministrator. Set Time Set GMT/local time conversion and the Parametercurrent and allowable magnitude of user adjustments to RTC 528 time.Channel Services Manager Requests Bind Time Bind timer services to achannel as an event source Unbind Time Unbind timer services from achannel as an event source. Set Alarm Sets an alarm notification for aspecific time. The user will be notified by an alarm event at the timeof the alarm. Parameters to this request determine the event, frequency,and requested processing for the alarm. Clear Alarm Cancels a requestedalarm notification.

[1055] SPU Encryption/Decryption Manager 556

[1056] The Encryption/Decryption Manager 556 supports calls to thevarious encryption/decryption techniques supported by SPE 503/HPE 655.It may be supported by a hardware-based encryption/decryption engine 522within SPU 500. Those encryption/decryption technologies not supportedby SPU encrypt/decrypt engine 522 may be provided by encrypt/decryptmanager 556 in software. The primary bulk encryption/decryption loadmodules preferably are loaded at all times, and the load modulesnecessary for other algorithms are preferably paged in as needed. Thus,if the primary bulk encryption/decryption algorithm is DES, only the DESload modules need be permanently resident in the RAM 534 a of SPE503/HPE 655.

[1057] The following are examples of RPC calls supported byEncrypt/Decrypt Manager 556 in the preferred embodiment. Call NameDescription PK Encrypt Encrypt a block using a PK (public key)algorithm. PK Decrypt Decrypt a block using a PK algorithm. DES EncryptEncrypt a block using DES. DES Decrypt Decrypt a block using DES. RC-4Encrypt a block using the RC-4 (or other bulk Encrypt encryption)algorithm. RC-4 Decrypt a block using the RC-4 (or other bulk Decryptencryption) algorithm. Initialize Initialize DES instance to be used.DES Instance Initialize Initialize RC-4 instance to be used. RC-4Instance Initialize Initialize MD5 instance to be used. MD5 InstanceProcess MD5 Process MD5 block. Block

[1058] The call parameters passed may include the key to be used; mode(encryption or decryption); any needed Initialization Vectors; thedesired cryptographic operating (e.g., type of feedback); theidentification of the cryptographic instance to be used: and the startaddress, destination address, and length of the block to be encrypted ordecrypted.

[1059] SPU Key and Tag Manager 558

[1060] The SPU Key and Tag Manager 558 supports calls for key storage,key and management file tag look up, key convolution, and the generationof random keys, tags, and transaction numbers.

[1061] The following table shows an example of a list of SPE/HPE key andtag manager service 558 calls: Call Name Description Key Requests GetKey Retrieve the requested key. Set Key Set (store) the specified keyGenerate Key Generate a key (pair) for a specified algorithm GenerateGenerate a key using a specified convolution Convoluted Key algorithmand algorithm parameter block. Get Convolution Return the currently set(default) convolution Algorithm parameters for a specific convolutionalgorithm. Set Convolution Sets the convolution parameters for aspecific Algorithm convolution algorithm (calling routine must provide atag to read returned contents) Tag Requests Get Tag Get the validation(or other) tag for a specific VDE Item ID Set Tag Set the validation (orother) tag for a specific VDE Item ID to a known value Calculate HashBlock Calculate the “hash block number” for a specific Number VDE ItemID Set Hash Parameters Set the hash parameters and hash algorithm Forcesa resynchronization of the hash table Get Hash Parameters Retrieve thecurrent hash parameters/algorithm. Synchronize Synchronize themanagement files and rebuild Management the hash block tables based oninformation Files found in the tables. Reserved for VDE administrator

[1062] Keys and tags may be securely generated within SPE 503 (HPE 655)in the preferred embodiment. The key generation algorithm is typicallyspecific to each type of encryption supported. The generated keys may bechecked for cryptographic weakness before they are used. A request forKey and Tag Manager 558 to generate a key, tag and/or transaction numberpreferably takes a length as its input parameter. It generates a randomnumber (or other appropriate key value) of the requested length as itsoutput.

[1063] The key and tag manager 558 may support calls to retrievespecific keys from the key storage areas in SPU 500 and any keys storedexternal to the SPU The basic format of the calls is to request keys bykey type and key number. Many of the keys are periodically updatedthrough contact with the VDE administrator, and are kept within SPU 500in NVRAM 534 b or EEPROM because these memories are secure, updatableand non-volatile

[1064] SPE 503/HPE 655 may support both Public Key type keys and BulkEncryption type keys The public key (PK) encryption type keys stored bySPU 500 and managed by key and tag manager 558 may include, for example,a device public key, a device private key, a PK certificate, and apublic key for the certificate. Generally, public keys and certificatescan be stored externally in non-secured memory if desired, but thedevice private key and the public key for the certificate should only bestored internally in an SPU 500 EEPROM or NVRAM 534 b. Some of the typesof bulk encryption keys used by the SPU 500 may include, for example,general-purpose bulk encryption keys, administrative object privateheader keys, stationary object private header keys, traveling objectprivate header keys, download/initialization keys, backup keys, trailkeys, and management file keys.

[1065] As discussed above, preferred embodiment Key and Tag Manager 558supports requests to adjust or convolute keys to make new keys that areproduced in a deterministic way dependent on site and/or time, forexample. Key convolution is an algorithmic process that acts on a keyand some set of input parameters) to yield a new key It can be used, forexample, to increase the number of keys available for use withoutincurring additional key storage space It may also be used, for example,as a process to “age” keys by incorporating the value of real-time RTC528 as parameters. It can be used to make keys site specific byincorporating aspects of the site ID as parameters.

[1066] Key and Tag Manager 558 also provides services relating to taggeneration and management. In the preferred embodiment, transaction andaccess tags are preferably stored by SPE 503 (HPE 655) in protectedmemory (e.g., within the NVRAM 534 b of SPU 500). These tags may begenerated by key and tag manager 558. They are used to, for example,check access rights to, validate and correlate data elements. Forexample, they may be used to ensure components of the secured datastructures are not tampered with outside of the SPU 500. Key and tagmanager 558 may also support a trail transaction tag and acommunications transaction tag.

[1067] SPU Summary Services Manager 560

[1068] SPE 503 maintains an audit trail in reprogrammable non-volatilememory within the SPU 500 and/or in secure database 610. This audittrail may consist of an audit summary of budget activity for financialpurposes, and a security summary of SPU use When a request is made tothe SPU, it logs the request as having occurred and then notes whetherthe request succeeded or failed. All successful requests may be summedand stored by type in the SPU 500 Failure information, including theelements listed below, may be saved along with details of the failure.Control Information Retained in an SPE on Access Failures Object ID UserID Type of failure Time of failure

[1069] This information may be analyzed to detect cracking attempts orto determine patterns of usage outside expected (and budgeted) norms.The audit trail histories in the SPU 500 may be retained until the auditis reported to the appropriate parties. This will allow both legitimatefailure analysis and attempts to cryptoanalyze the SPU to be noted.

[1070] Summary services manager 560 may store and maintain this internalsummary audit information. This audit information can be used to checkfor security breaches or other aspects of the operation of SPE 503. Theevent summaries may be maintained, analyzed and used by SPE 503 (HPE655) or a VDE administrator to determine and potentially limit abuse ofelectronic appliance 600 In the preferred embodiment, such parametersmay be stored m secure memory (e.g., within the NVRAM 534 b of SPU 500).

[1071] There are two basic structures for which summary services areused in the preferred embodiment. One (the “event summary datastructure”) is VDE administrator specific and keeps track of events. Theevent summary structure may be maintained and audited during periodiccontact with DE administrators. The other is used by VDE administratorsand/or distributors for overall budget. A VDE administrator may registerfor event summaries and an overall budget summary at the time anelectronic appliance 600 is initialized. The overall budget summary maybe reported to and used by a VDE administrator in determiningdistribution of consumed budget (for example) in the case of corruptionof secure management files 610. Participants that receive appropriatepermissions can register their processes (e.g., specific budgets) withsummary services manager 560, which may then reserve protected memoryspace (e.g., within NVRAM 534 b) and keep desired use and/or accessparameters. Access to and modification of each summary can be controlledby its own access tag.

[1072] The following table shows an example or a list of PPE summaryservice manager 560 service calls. Call Name Description Create summaryCreate a summary service if the user info has a “ticket” that permitsher to request this service Get value Return the current value of thesummary service. The caller must present an appropriate tag (and/or“ticket”) to use this request. Set value Set the value of a summaryservice. Increment Increment the specified summary service (e.g., ascalar meter summary data area). The caller must present an appropriatetag (and/or “ticket”) to use this request. Destroy Destroy the specifiedsummary service if the user has a tag and/or “ticket” that permits themto request this service.

[1073] In the preferred embodiment, the event summary data structureuses a fixed event number to index into a look up table. The look uptable contains a value that can be configured as a counter or a counterplus limit. Counter mode may be used by VDE administrators to determinedevice usage. The limit mode may be used to limit tampering and attemptsto misuse the electronic appliance 600. Exceeding a limit will result inSPE 503 (HPE 655) refusing to service user requests until it is reset bya VDE administrator Calls to the system wide event summary process maypreferably be built into all load modules that process the events thatare of interest.

[1074] The following table shows examples of events that may beseparately metered by the preferred embodiment event summary datastructure: Event Type Successful Initialization completed successfully.Events User authentication accepted. Communications established. Channelloads set for specified values. Decryption completed. Key informationundated. New budget created or existing budget updated. New billinginformation generated or existing billing undated. New meter set up orexisting meter updated. New PERC created or existing PERC updated. Newobjects registered. Administrative objects successfully processed. Auditprocessed successfully All other events. Failed Events Initializationfailed. Authentication failed. Communication attempt failed. Request toload a channel failed. Validation attempt unsuccessful. Link tosubsidiary item failed correlation tag match. Authorization attemptfailed. Decryption attempt failed. Available budget insufficient tocomplete requested procedure. Audit did not occur. Administrative objectdid not process correctly. Other failed events.

[1075] Another, “overall currency budget” summary data structuremaintained by the preferred embodiment summary services manager 560allows registration of VDE electronic appliance 600. The first entry isused for an overall currency budget consumed value, and is registered bythe VDE administrator that first initializes SPE 503 (HPE 655). Certaincurrency consuming load modules and audit load modules that complete theauditing process for consumed currency budget may call the summaryservices manager 560 to update the currency consumed value. Specialauthorized load modules may have access to the overall currency summary,while additional summaries can be registered for by individualproviders.

[1076] SPE Authentication Manager/Service Communications Manager 564

[1077] The Authentication Manager/Service Communications Manager 564supports calls for user password validation and “tickets” generation andvalidation. It may also support secure communications between SPE 503and an external node or device (e.g., a VDE administrator ordistributor). It may support the following examples ofauthentication-related service requests in the preferred embodiment:Call Name Description User Services Create User Creates a new user andstores Name Services Records (NSRs) for use by the Name Services Manager752. Authenticate Authenticates a user for use of the system. User Thisrequest lets the caller authenticate as a specific user ID. Groupmembership is also authenticated by this request. The authenticationreturns a “ticket” for the user Delete User Deletes a user's NSR andrelated records Ticket Services Generate Generates a “ticket” for use ofone or more Ticket services. Authenticate Authenticates a “ticket.”Ticket

[1078] Not included in the table above are calls to the securecommunications service. The secure communications service provided bymanager 564 may provide (e.g., in conjunction with low-level servicesmanager 582 if desired) secure communications based on a public key (orothers) challenge-response protocol. This protocol is discussed infurther detail elsewhere in this document. Tickets identify users withrespect to the electronic appliance 600 in the case where the appliancemay be used by multiple users. Tickets may be requested by and returnedto VDE software applications through a ticket-granting protocol (e.g.,Kerberos). VDE components may require tickets to be presented in orderto authorize particular services.

[1079] SPE Secure Database Manger 566

[1080] Secure database manager 566 retrieves, maintains and storessecure database records within secure database 610 on memory external toSPE 503. Many of these secure database files 610 are in encrypted form.All secure information retrieved by secure database manager 566therefore must be decrypted by encrypt/decrypt manager 556 before use.Secure information (e.g., records of use) produced by SPE 503 (HPE 655)which must be stored external to the secure execution environment arealso encrypted by encrypt decrypt manager 556 before they are stored viasecure database manager 566 in a secure database file 610.

[1081] For each VDE item loaded into SPE 503, Secure Database manager566 in the preferred embodiment may search a master list for the VDEitem ID, and then check the corresponding transaction tag against theone in the item to ensure that the item provided is the current item.Secure Database Manager 566 may maintain list of VDE item ID andtransaction tags in a “hash structure” that can be paged into SPE 503 toquickly locate the appropriate VDE item ID. In smaller systems, a lookup table approach may be used. In either case, the list should bestructured as a pagable structure that allows VDE item ID to be locatedquickly.

[1082] The “hash based” approach may be used to sort the list into “hashbuckets” that may then be accessed to provide more rapid and efficientlocation of items in the list. In the “hash based” approach, the VDEitem IDs are “hashed” through a subset of the full item ID and organizedas pages of the “hashed” table. Each “hashed” page may contain the restof the VDE item ID and current transaction tag for each item associatedwith that page. The “hash” table page number may be derived from thecomponents of the VDE item ID, such as distribution ID, item ID, siteID, user ID, transaction tag, creator ID, type and/or version. Thehashing algorithm (both the algorithm itself and the parameters to behashed may be configurable by a VDE administrator on a site by sitebasis to provide optimum hash page use. An example of a hash pagestructure appears below: Field Hash Page Header Distributor ID Item IDSite ID User ID Transaction Tag Hash Page Entry Creator ID Item ID TypeVersion Transaction Tag

[1083] In this example, each hash page may contain all of the VDE itemIDs and transaction tags for items that have identical distributor ID,item ID, and user ID fields (site ID will be fixed for a givenelectronic appliance 600). These four pieces of information may thus beused as hash algorithm parameters.

[1084] The “hash” pages may themselves be frequently updated, and shouldcarry transaction tags that are checked each time a “hash” page isloaded. The transaction tag may also be updated each time a “hash” pageis written out.

[1085] As an alternative to the hash-based approach, if the number ofupdatable items is kept small (such as in a dedicated consumerelectronic appliance 600), then assigning each updatable item a uniquesequential site record number as part of its VDE item ID may allow alook up table approach to be used. Only a small number of bytes oftransaction tag are needed per item, and a table transaction tag for allfrequently updatable items can be kept in protected memory such as SPUNVRAM 534 b.

[1086] Random Value Generator Manager 565

[1087] Random Value Generator Manager 565 may generate random values. Ifa hardware-based SPU random value generator 542 is present, the RandomValue Generator Manager 565 may use it to assist in generating randomvalues.

[1088] Other SPE RPC Services 592

[1089] Other authorized RPC services may be included in SPU 500 byhaving them “register” themselves in the RPC Services Table and addingtheir entries to the RPC Dispatch Table For example, one or morecomponent assemblies 690 may be used to provide additional services asan integral part of SPE 503 and its associated operating system.Requests to services not registered in these tables will be passed outof SPE 503 (HPE 655) for external servicing.

[1090] SPE 503 Performance Considerations

[1091] Performance of SPE 503 (HPE 655) is a function of:

[1092] complexity of the component assemblies used

[1093] number of simultaneous component assembly operations

[1094] amount of internal SPU memory available

[1095] speed of algorithm for block encryption/decryption

[1096] The complexity of component assembly processes along with thenumber of simultaneous component assembly processes is perhaps theprimary factor in determining performance. These factors combine todetermine the amount of code and data and must be resident in SPU 500 atany one time (the minimum device size) and thus the number of devicesize “chunks” the processes must be broken down into. Segmentationinherently increases run time size over simpler models. Of course,feature limited versions of SPU 500 may be implemented usingsignificantly smaller amounts of RAM 534. “Aggregate” load modules asdescribed above may remove flexibility in configuring VDE structures andalso further limit the ability of participants to individually updateotherwise separated elements, but may result in a smaller minimum devicesize. A very simple metering version of SPU 500 can be constructed tooperate with minimal device resources.

[1097] The amount of RAM 534 internal to SPU 500 has more impact on theperformance of the SPE 503 than perhaps any other aspect of the SPU. Theflexible nature of VDE processes allows use of a large number of loadmodules, methods and user data elements. It is impractical to store morethan a small number of these items in ROM 532 within SPU 500. Most ofthe code and data structures needed to support a specific VDE processwill need to be dynamically loaded into the SPU 500 for the specific VDEprocess when the process is invoked. The operating system within SPU 500then may page in the necessary VDE items to perform the process. Theamount of RAM 534 within SPU 500 will directly determine how large anysingle VDE load module plus its required data can be, as well as thenumber of page swaps that will be necessary to run a VDE process. TheSPU I/O speed, encryption/decryption speed, and the amount of internalmemory 532, 534 will directly affect the number of page swaps requiredin the device. Insecure external memory may reduce the wait time forswapped pages to be loaded into SPU 500, but will still incursubstantial encryption/decryption penalty for each page.

[1098] In order to maintain security. SPE 503 must encrypt andcryptographically seal each block being swapped out to a storage deviceexternal to a supporting SPU 500, and must similarly decrypt, verify thecryptographic seal for, and validate each block as it is swapped intoSPU 500. Thus, the data movement and encryption/decryption overhead foreach swap block has a very large impact on SPE performance.

[1099] The performance of an SPU microprocessor 520 may notsignificantly impact the performance of the SPE 503 it supports if theprocessor is not responsible for moving data through the encrypt/decryptengine 522.

[1100] VDE Secure Database 610

[1101] VDE 100 stores separately deliverable VDE elements in a secure(e.g., encrypted) database 610 distributed to each VDE electronicappliance 610. The database 610 in the preferred embodiment may storeand/or manage three basic classes of VDE items:

[1102] VDE objects,

[1103] VDE process elements, and

[1104] VDE data structures.

[1105] The following table lists examples of some of VDE items stored inor managed by information stored in secure database 610: Class BriefDescription Objects Content Objects Provide a container for content.Administrative Provide a container for Objects information used to keepVDE 100 operating. Traveling Objects Provide a container for content andcontrol information. Smart Objects Provide a container for(user-specified) processes and data. Process Method Cores Provide amechanism to Elements relate events to control mechanisms andpermissions. Load Modules Secure (tamper-resistant) (”LMs“) executablecode. Method Data Independently deliverable Elements (”MDEs“) datastructures used to control/customize methods. Data Permissions RecordsPermissions to use Structures (”PERCs“) objects; ”blueprints“ to buildcomponent assemblies. User Data Elements Basic data structure for(”UDEs“) storing information used in conjunction with load modules.Administrative Data Used by VDE node to Structures maintainadministrative information.

[1106] Each electronic appliance 600 may have an instance of a securedatabase 610 that securely maintains the VDE items. FIG. 16 shows oneexample of a secure database 610. The secure database 610 shown in thisexample includes the following VDE-protected items:

[1107] one or more PERCs 808;

[1108] methods 1000 (including static and dynamic method “cores” 1000,and MDEs 1202);

[1109] Static UDEs 1200 a and Dynamic UDEs 1200 b; and

[1110] load modules 1100.

[1111] Secure database 610 may also include the following additionaldata structures used and maintained for administrative purposes:

[1112] an “object registry” 450 that references an object storage 728containing one or more VDE objects;

[1113] name service records 452; and

[1114] configuration records 454 (including site configuration records456 and user configuration records 458).

[1115] Secure database 610 in the preferred embodiment does not includeVDE objects 300, but rather references VDE objects stored, for example,on file system 687 and/or in a separate object repository 728.Nevertheless, an appropriate “starting point” for understandingVDE-protected information may be a discussion of VDE objects 300.

[1116] VDE Objects 300

[1117] VDE 100 provides a media independent container model forencapsulating content. FIG. 17 shows an example of a “logical” structureor format 800 for an object 300 provided by the preferred embodiment.

[1118] The generalized “logical object” structure 800 shown in FIG. 17used by the preferred embodiment supports digital content delivery overany currently used media. “Logical object” in the preferred embodimentmay refer correctively to: content: computer software and/or methodsused to manipulate, record, and/or otherwise control use of saidcontent; and permissions, limitations, administrative controlinformation and/or requirements applicable to said content, and/or saidcomputer software and/or methods. Logical objects may or may not bestored, and may or may not be present in, or accessible to, any evenelectronic appliance 600. The content portion of a logical object may beorganized as information contained in, not contained in, or partiallycontained in one or more objects.

[1119] Briefly, the FIG. 17 “logical object” structure 800 in thepreferred embodiment includes a public header 802, private header 804, a“private body” 806 containing one or more methods 1000, permissionsrecord(s) (PERC) 808 (which may include one or more key blocks 810), andone or more data blocks or areas 812. These elements may be “packaged”within a “container” 302. This generalized, logical object structure 800is used in the preferred embodiment for different types of VDE objects300 categorized by the type and location of their content.

[1120] The “container” concept is a convenient metaphor used to give aname to the collection of elements required to make use of content or toperform an administrative-type activity. Container 302 typicallyincludes identifying information, control structures and content (e.g.,a property or administrative data). The term “container” is often (e.g.,Bento/OpenDoc and OLE) used to describe a collection of informationstored on a computer system's secondary storage system(s) or accessibleto a computer system over a communications network on a “server's”secondary storage system. The “container” 302 provided by the preferredembodiment is not so limited or restricted. In VDE 100, there is norequirement that this information is stored together, received at thesame time, updated at the same time, used for only a single object, orbe owned by the same entity. Rather, in VDE 100 the container concept isextended and generalized to include real-time content and/or onlineinteractive content passed to an electronic appliance over a cable, bybroadcast, or communicated by other electronic communication means.

[1121] Thus, the “complete” VDE container 302 or logical objectstructure 800 may not exist at the user's location (or any otherlocation, for that matter) at any one time. The “logical object” mayexist over a particular period of time (or periods of time), rather thanall at once. This concept includes the notion of a “virtual container”where important container elements may exist either as a plurality oflocations and/or over a sequence of time periods (which may or may notoverlap). Of course, VDE 100 containers can also be stored with allrequired control structures and content together. This represents acontinuum from all content and control structures present in a singlecontainer, to no locally accessible content or container specificcontrol structures.

[1122] Although at least some of the data representing the object istypically encrypted and thus its structure is not discernible, within aPPE 650 the object may be viewed logically as a “container” 302 becauseits structure and components are automatically and transparentlydecrypted.

[1123] A container model merges well with the event-driven processes andROS 602 provided by the preferred embodiment. Under this model, contentis easily subdivided into small, easily manageable pieces, but is storedso that it maintains the structural richness inherent in unencryptedcontent. An object oriented container model (such as Bento/OpenDoc orOLE) also provides many of the necessary “hooks” for inserting thenecessary operating system integration components, and for defining thevarious content specific methods.

[1124] In more detail, the logical object structure 800 provided by thepreferred embodiment includes a public (or unencrypted) header 802 thatidentifies the object and may also identify one or more owners of rightsin the object and/or one or more distributors of the object. Private (orencrypted) header 804 may include a part or all of the information inthe public header and further, in the preferred embodiment, will includeadditional data for validating and identifying the object 300 when auser attempts to register as a user of the object with a serviceclearinghouse, VDE administrator, or an SPU 500. Alternatively,information identifying one or more rights owners and/or distributors ofthe object may be located in encrypted form within encrypted header 804,along with any of said additional validating and identifying data.

[1125] Each logical object structure 800 may also include a “privatebody” 806 containing or referencing a set of methods 1000 (i.e.,programs or procedures) that control use and distribution of the object300. The ability to optionally incorporate different methods 1000 witheach object is important to making VDE 100 highly configurable. Methods1000 perform the basic function of defining what users (including, whereappropriate, distributors, client administrators, etc.), can and cannotdo with an object 300. Thus, one object 300 may come with relativelysimple methods, such as allowing unlimited viewing within a fixed periodof time for a fixed fee (such as the newsstand price of a newspaper forviewing the newspaper for a period of one week after the paper'spublication), while other objects may be controlled by much morecomplicated e.g., billing and usage limitation) methods.

[1126] Logical object structure 800 shown in FIG. 17 may also includeone or more PERCs 808. PERCs 808 govern the use of an object 300,specifying methods or combinations of methods that must be used toaccess or otherwise use the object or its contents. The permissionrecords 808 for an object may include key block(s) 810, which may storedecryption keys for accessing the content of the encrypted contentstored within the object 300.

[1127] The content portion of the object is typically divided intoportions called data blocks 812. Data blocks 812 may contain any sort ofelectronic information, such as, “content,” including computer programs,images, sound, VDE administrative information, etc. The size and numberof data blocks 812 may be selected by the creator of the property. Datablocks 812 need not all be the same size (size may be influenced bycontent usage, database format, operating system, security and/or otherconsiderations). Security will be enhanced by using at least one keyblock 810 for each data block 812 in the object, although this is notrequired. Key blocks 810 may also span portions of a plurality of datablocks 812 in a consistent or pseudo-random manner. The spanning mayprovide additional security by applying one or more keys to fragmentedor seemingly random pieces of content contained in an object 300,database, or other information entity

[1128] Many objects 300 that are distributed by physical media and/or by“out of channel” means (e.g., redistributed after receipt by a customerto another customer) might not include key blocks 810 in the same object300 that is used to transport the content protected by the key blocks.This is because VDE objects may contain data that can be electronicallycopied outside the confines of a VDE node. If the content is encrypted,the copies will also be encrypted and the copier cannot gain access tothe content unless she has the appropriate decryption key(s). Forobjects in which maintaining security is particularly important, thepermission records 808 and key blocks 810 will frequently be distributedelectronically, using secure communications techniques (discussed below)that are controlled by the VDE nodes of the sender and receiver. As aresult, permission records 808 and key blocks 810 will frequently, inthe preferred embodiment, be stored only on electronic appliances 600 ofregistered users (and may themselves be delivered to the user as part ofa registration/initialization process). In this instance, permissionrecords 808 and key blocks 810 for each property can be encrypted with aprivate DES key that is stored only in the secure memory of an SPU 500,making the key blocks unusable on any other user's VDE node.Alternately, the key blocks 810 can be encrypted with the end user'spublic key, making those key blocks usable only to the SPU 500 thatstores the corresponding private key (or other, acceptably secure,encryption security techniques can be employed).

[1129] In the preferred embodiment, the one or more keys used to encrypteach permission record 808 or other management information record willbe changed every time the record is updated (or after a certain one ormore events). In this event, the updated record is re-encrypted with newone or more keys. Alternately, one or more of the keys used to encryptand decrypt management information may be “time aged” keys thatautomatically become invalid after a period of time. Combinations oftime aged and other event triggered keys may also be desirable; forexample keys may change after a certain number of accesses, and/or aftera certain duration of time or absolute point in time. The techniques mayalso be used together for any given key or combination of keys. Thepreferred embodiment procedure for constructing time aged keys is aone-way convolution algorithm with input parameters including user andsite information as well as a specified portion of the real time valueprovided by the SPU RTC 528. Other techniques for time aging may also beused, including for example techniques that use only user or siteinformation, absolute points in time, and/or duration of time related toa subset of activities related to using or decrypting RIDE securedcontent or the use of the RIDE system.

[1130] VDE 100 supports many different types of “objects” 300 having thelogical object structure 800 shown in FIG. 17. Objects may be classifiedin one sense based on whether the protection information is boundtogether with the protected information. For example, a container thatis bound by its control(s) to a specific VDE node is called a“stationary object” (see FIG. 18). A container that is not bound by itscontrol information to a specific VDE node but rather carries sufficientcontrol and permissions to permit its use, in whole or in part, at anyof several sites is called a “Traveling Object” (see FIG. 19).

[1131] Objects may be classified in another sense based on the nature ofthe information they contain. A container with information content iscalled a “Content Object” (see FIG. 20). A container that containstransaction information, audit trails. VDE structures, and/or other VDEcontrol/administrative information is called an “Administrative Object”(see FIG. 21). Some containers that contain executable code operatingunder VDE control as opposed to being VDE control information are called“Smart Objects.” Smart Objects support user agents and provide controlfor their execution at remote sites. There are other categories ofobjects based upon the location, type and access mechanism associatedwith their content, that can include combinations of the types mentionedabove. Some of these objects supported by VDE 100 are described below.Some or all of the data blocks 812 shown in FIG. 17 may include“embedded” content, administrative, stationary, traveling and/or otherobjects.

[1132] 1. Stationary Objects

[1133]FIG. 18 shows an example of a “Stationary Object” structure 850provided by the preferred embodiment. “Stationary Object” structure 850is intended to be used only at specific VDE electronicappliance/installations that have received explicit permissions to useone or more portions of the stationary object. Therefore, stationaryobject structure 850 does not contain a permissions record (PERC) 808;rather, this permissions record is supplied and/or delivered separately(e.g., at a different time, over a different path, and/or by a differentparty) to the appliance/installation 600. A common PERC 808 may be usedwith many different stationary objects.

[1134] As shown in FIG. 18, public header 802 is preferably “plaintext”(i.e., unencrypted). Private header 804 is preferably encrypted using atleast one of many “private header keys.” Private header 804 preferablyalso includes a copy of identification elements from public header 802,so that if the identification information in the plaintext public headeris tampered with, the system can determine precisely what the tampererattempted to alter. Methods 1000 may be contained in a section calledthe “private body” 806 in the form of object local methods, loadmodules, and/or user data elements. This private body (method) section806 is preferably encrypted using one or more private body keyscontained in the separate permissions record 808. The data blocks 812contain content (information or administrative) that may be encryptedusing one or more content keys also provided in permissions record 808.

[1135] 2. Traveling Objects

[1136]FIG. 19 shows an example of a “traveling object” structure 860provided by the preferred embodiment. Traveling objects are objects thatcarry with them sufficient information to enable at least some use of atleast a portion of their content when they arrive at a VDE node

[1137] Traveling object structure 860 may be the same as stationaryobject structure 850 shown in FIG. 18 except that the traveling objectstructure includes a permissions record (PERC) 808 within private header804. The inclusion of PERC 808 within traveling object structure 860permits the traveling object to be used at any VDE electronicappliance/participant 600 (in accordance with the methods 1000 and thecontained PERC 808).

[1138] “Traveling” objects are a class of VDE objects 300 that canspecifically support “out of channel” distribution. Therefore, theyinclude key block(s) 810 and are transportable from one electronicappliance 600 to another. Traveling objects may come with a quitelimited usage related budget so that a user may use, in whole or part,content (such as a computer program, game, or database) and evaluatewhether to acquire a license or further license or purchase objectcontent. Alternatively, traveling object PERCs 808 may contain orreference budget records with, for example:

[1139] (a) budget(s) reflecting previously purchased rights or creditfor future licensing or purchasing and enabling at least one or moretypes of object content usage, and/or

[1140] (b) budget(s) that employ (and may debit) available credit(s)stored on and managed by the local VDE node in order to enable objectcontent use, and/or

[1141] (c) budget(s) reflecting one or more maximum usage criteriabefore a report to a local VDE node (and, optionally, also a report to aclearinghouse) is required and which may be followed by a reset allowingfurther usage, and/or modification of one or more of the original one ormore budget(s).

[1142] As with standard VDE objects 300, a user may be required tocontact a clearinghouse service to acquire additional budgets if theuser wishes to continue to use the traveling object after the exhaustionof an available budget(s) or if the traveling object (or a copy thereof)is moved to a different electronic appliance and the new appliance doesnot have a available credit budget(s) that corresponds to therequirements stipulated by permissions record 808.

[1143] For example, a traveling object PERC 808 may include a referenceto a required budget VDE 1200 or budget options that may be found and/orare expected to be available. For example, the budget VDE may referencea consumers VISA, MC, AMEX, or other “generic” budget that may be objectindependent and may be applied towards the use of a certain or classesof traveling object content (for example any movie object from a classof traveling objects that might be Blockbuster Video rentals). Thebudget VDE itself may stipulate one or more classes of objects it may beused with, while an object may specifically reference a certain one ormore generic budgets Under such circumstances, VDE providers willtypically make information available in such a manner as to allowcorrect referencing and to enable billing handling and resultingpayments.

[1144] Traveling objects can be used at a receiving VDE node electronicappliance 600 so long as either the appliance carries the correct budgetor budget type (e.g. sufficient credit available from a clearinghousesuch as a VISA budget) either in general or for specific one or moreusers or user classes, or so long as the traveling object itself carrieswith it sufficient budget allowance or an appropriate authorization(e.g., a stipulation that the traveling object may be used on certainone or more installations or installation classes or users or userclasses where classes correspond to a specific subset of installationsor users who are represented by a predefined class identifiers stored ina secure database 610). After receiving a traveling object, if the user(and/or installation) doesn't have the appropriate budget(s) and/orauthorizations, then the user could be informed by the electronicappliance 600 (using information stored in the traveling object) as towhich one or more parties the user could contact. The party or partiesmight constitute a list of alternative clearinghouse providers for thetraveling object from which the user selects his desired contact).

[1145] As mentioned above, traveling objects enable objects 300 to bedistributed “Out-Of-Channel;” that is, the object may be distributed byan unauthorized or not explicitly authorized individual to anotherindividual. “Out of channel” includes paths of distribution that allow,for example, a user to directly redistribute an object to anotherindividual. For example, an object provider might allow users toredistribute copies of an object to their friends and associates (forexample by physical delivery of storage media or by delivery over acomputer network) such that if a friend or associate satisfies anycertain criteria required for use of said object, he may do so.

[1146] For example, if a software program was distributed as a travelingobject, a user of the program who wished to supply it or a usable copyof it to a friend would normally be free to do so. Traveling Objectshave great potential commercial significance. since useful content couldbe primarily distributed by users and through bulletin boards, whichwould require little or no distribution overhead apart from registrationwith the “original” content provider and/or clearinghouse

[1147] The “out of channel” distribution may also allow the provider toreceive payment for usage and/or elsewise maintain at least a degree ofcontrol over the redistributed object. Such certain criteria mightinvolve, for example, the registered presence at a user's VDE node of anauthorized third party financial relationship, such as a credit card,along with sufficient available credit for said usage.

[1148] Thus, if the user had a VDE node, the user might be able to usethe traveling object if he had an appropriate, available budgetavailable on his VDE node (and if necessary, allocated to him), and/orif he or his VDE node belonged to a specially authorized group of usersor installations and/or if the traveling object carried its ownbudget(s).

[1149] Since the content of the traveling object is encrypted, it can beused only under authorized circumstances unless the traveling objectprivate header key used with the object is broken—a potentially easiertask with a traveling object as compared to, for example, permissionsand/or budget information since many objects may share the same key,giving a cryptoanalyst both more information in cyphertext to analyzeand a greater incentive to perform cryptoanalysis.

[1150] In the case of a “traveling object,” content owners maydistribute information with some or all of the key blocks 810 includedin the object 300 in which the content is encapsulated. Putting keys indistributed objects 300 increases the exposure to attempts to defeatsecurity mechanisms by breaking or cryptoanalyzing the encryptionalgorithm with which the private header is protected (e.g., bydetermining the key for the header's encryption). This breaking ofsecurity would normally require considerable skill and time, but ifbroken, the algorithm and key could be published so as to allow largenumbers of individuals who possess objects that are protected with thesame key(s) and algorithm(s) to illegally use protected information. Asa result, placing keys in distributed objects 300 may be limited tocontent that is either “time sensitive” (has reduced value after thepassage of a certain period of time), or which is somewhat limited invalue, or where the commercial value of placing keys in objects (forexample convenience to end-users, lower cost of eliminating thetelecommunication or other means for delivering keys and/or permissionsinformation and/or the ability to supporting objects going“out-of-channel”) exceeds the cost of vulnerability to sophisticatedhackers. As mentioned elsewhere, the security of keys may be improved byemploying convolution techniques to avoid storing “true” keys in atraveling object, although in most cases using a shared secret providedto most or all VDE nodes by a VDE administrator as an input rather thansite ID and/or time in order to allow objects to remain independent ofthese values.

[1151] As shown in FIG. 19 and discussed above, a traveling objectcontains a permissions record 808 that preferably provides at least somebudget (one, the other, or both, in a general case). Permission records808 can, as discussed above, contain a key block(s) 810 storingimportant key information. PERC 808 may also contain or refer to budgetscontaining potentially valuable quantities/values. Such budgets may bestored within a traveling object itself, or they may be deliveredseparately and protected by highly secure communications keys andadministrative object keys and management database techniques.

[1152] The methods 1000 contained by a traveling object will typicallyinclude an installation procedure for “elf registering” the object usingthe permission records 808 in the object (e.g., a REGISTER method). Thismay be especially useful for objects that have time limited value,objects (or properties) for which the end user is either not charged oris charged only a nominal fee (e.g., objects for which advertisersand/or information publishers are charged based on the number of endusers who actually access published information), and objects thatrequire widely available budgets and may particularly benefit fromout-of-channel distribution (e.g., credit card derived budgets forobjects containing properties such as movies, software programs, games,etc.). Such traveling objects may be supplied with or without containedbudget UDEs.

[1153] One use of traveling objects is the publishing of software, wherethe contained permission record(s) may allow potential customers to usethe software in a demonstration mode, and possibly to use the fullprogram features for a limited time before having to pay a license fee,or before having to pay more than an initial trial fee. For example,using a time based billing method and budget records with a smallpre-installed time budget to allow fill use of the program for a shortperiod of time. Various control methods may be used to avoid misuse ofobject contents For example, by setting the minimum registrationinterval for the traveling object to an appropriately large period oftime (e.g. a month, or six months or a year), users are prevented fromre-using the budget records in the same traveling object.

[1154] Another method for controlling the use of traveling objects is toinclude time-aged keys in the permission records that are incorporatedin the traveling object This is useful generally for traveling objectsto ensure that they will not be used beyond a certain date withoutre-registration, and is particularly useful for traveling objects thatare electronically distributed by broadcast, network, ortelecommunications (including both one and two way cable), since thedate and time of delivery of such traveling objects aging keys can beset to accurately correspond to the time the user came into possessionof the object.

[1155] Traveling objects can also be used to facilitate “moving” anobject from one electronic appliance 600 to another. A user could move atraveling object, with its incorporated one or more permission records808 from a desktop computer, for example, to his notebook computer. Atraveling object might register its user within itself and thereafteronly be useable by that one user. A traveling object might maintainseparate budget information, one for the basic distribution budgetrecord, and another for the “active” distribution budget record of theregistered user. In this way, the object could be copied and passed toanother potential user, and then could be a portable object for thatuser.

[1156] Traveling objects can come in a container which contains otherobjects. For example, a traveling object container can include one ormore content objects and one or more administrative objects forregistering the content object(s) in an end user's object registryand/or for providing mechanisms for enforcing permissions and/or othersecurity functions. Contained administrative object(s) may be used toinstall necessary permission records and/or budget information in theend user's electronic appliance.

[1157] Content Objects

[1158]FIG. 20 shows an example of a VDE content object structure 880.Generally, content objects 880 include or provide information content.This “content” may be any sort of electronic information. For example,content may include: computer software, movies, books, music,information databases, multimedia information, virtual realityinformation, machine instructions, computer data files, communicationsmessages and/or signals, and other information, at least a portion ofwhich is used and/or manipulated by one or more electronic appliancesVDE 100 can also be configured for authenticating, controlling, and orauditing electronic commercial transactions and communications such asinter-bank transactions, electronic purchasing communications, and thetransmission of, auditing of, and secure commercial archiving of,electronically signed contracts and other legal documents; theinformation used for these transactions may also be termed “content.” Asmentioned above, the content need not be physically stored within theobject container but may instead be provided separately at a differenttime (e.g., a real time feed over a cable).

[1159] Content object structure 880 in the particular example shown inFIG. 20 is a type of stationary object because it does not include aPERC 808. In this example, content object structure 880 includes, as atleast part of its content 812, at least one embedded content object 882as shown in FIG. 5A. Content object structure 880 may also include anadministrative object 870. Thus, objects provided by the preferredembodiment may include one or more “embedded” objects.

[1160] Administrative Objects

[1161]FIG. 21 shows an example of an administrative object structure 870provided by the preferred embodiment. An “administrative object”generally contains permissions, administrative control information,computer software and/or methods associated with the operation of VDE100. Administrative objects may also or alternatively contain records ofuse, and/or other information used in, or related to, the operation ofVDE 100. An administrative object may be distinguished from a contentobject by the absence of VDE protected “content” for release to an enduser for example. Since objects may contain other objects, it ispossible for a single object to contain one or more content containingobjects and one or more administrative objects. Administrative objectsmay be used to transmit information between electronic appliances forupdate, usage reporting, billing and/or control purposes. They containinformation that helps to administer VDE 100 and keep it operatingproperly. Administrative objects generally are sent between two VDEnodes, for example, a VDE clearinghouse service, distributor, or clientadministrator and an end user's electronic appliance 600.

[1162] Administrative object structure 870 in this example includes apublic header 802, private header 804 (including a “PERC” 808) and a“private body” 806 containing methods 1000 Administrative objectstructure 870 in this particular example shown in FIG. 20 is a type oftraveling object because it contains a PERC 808, but the administrativeobject could exclude the PERC 808 and be a stationary object. Ratherthan storing information content, administrative object structure 870stores “administrative information content” 872. Administrativeinformation content 872 may, for example, comprise a number of records872 a, 872 b, 872 n each corresponding to a different “event.” Eachrecord 872 a, 872 b, 872 n may include an “event” field 874, and mayoptionally include a parameter field 876 and/or a data field 878. Theseadministrative content records 872 may be used by RODE 100 to defineevents that may be processed during the course of transactions, e.g., anevent designed to add a record to a secure database might includeparameters 896 indicating how and where the record should be stored anddata field 878 containing the record to be added. In another example, acollection of events may describe a financial transaction between thecreator(s) of an administrative object and the recipient(s), such as apurchase, a purchase order, or an invoice. Each event record 872 may bea set of instructions to be executed by the end user's electronicappliance 600 to make an addition or modification to the end user'ssecure database 610. for example. Events can perform many basicmanagement functions, for example: add an object to the object registry,including providing the associated user/group record(s), rights records,permission record and/or method records; delete audit records (by“rolling up” the audit trail information into, for example, a morecondensed, e.g. summary form, or by actual deletion); add or updatepermissions records 808 for previously registered objects; add or updatebudget records; add or update user rights records; and add or updateload modules.

[1163] In the preferred embodiment, an administrative object may besent, for example, by a distributor, client administrator, or, perhaps,a clearinghouse or other financial service provider, to an end user, or,alternatively, for example, by an object creator to a distributor orservice clearinghouse. Administrative objects, for example, may increaseor otherwise adjust budgets and/or permissions of the receiving VDE nodeto which the administrative object is being sent. Similarly,administrative objects containing audit information in the data area 878of an event record 872 can be sent from end users to distributors,and/or clearinghouses and/or client administrators, who might themselvesfurther transmit to object creators or to other participants in theobject's chain of handling.

[1164] Methods

[1165] Methods 1000 in the preferred embodiment support many of theoperations that a user encounters in using objects and communicatingwith a distributor. They may also specify what method fields aredisplayable to a user (e.g., use events, user request events, userresponse events, and user display events) Additionally, if distributioncapabilities are supported in the method, then the method may supportdistribution activities, distributor communications with a user about amethod, method modification, what method fields are displayable to adistributor, and any distribution database checks and record keeping(e.g., distribution events, distributor request events, and distributorresponse events).

[1166] Given the generality of the existing method structure, and thediverse array of possibilities for assembling methods, a generalizedstructure may be used for establishing relationships between methods.Since methods 1000 may be independent of an object that requires themduring any given session, it is not possible to define the relationshipswithin the methods themselves. “Control methods” are used in thepreferred embodiment to define relationships between methods. Controlmethods may be object specific, and may accommodate an individualobject's requirements during each session.

[1167] A control method of an object establishes relationships betweenother methods. These relationships are parameterized with explicitmethod identifiers when a record set reflecting desired method optionsfor each required method is constructed during a registration process.

[1168] An “aggregate method” in the preferred embodiment represents acollection of methods that may be treated as a single unit. A collectionof methods that are related to a specific property, for example, may bestored in an aggregate method. This type of aggregation is useful froman implementation point of view because it may reduce bookkeepingoverhead and may improve overall database efficiency. In other cases,methods may be aggregated because they are logically coupled. Forexample, two budgets may be linked together because one of the budgetsrepresents an overall limitation, and a second budget represents thecurrent limitation available for use. This would arise if, for example,a large budget is released in small amounts over time.

[1169] For example, an aggregate method that includes meter, billing andbudget processes can be used instead of three separate methods. Such anaggregate method may reference a single “load module” 1100 that performsall of the functions of the three separate load modules and use only oneuser data element that contains meter, billing and budget data. Using anaggregate method instead of three separate methods may minimize overallmemory requirements, database searches, decryptions, and the number ofuser data element writes back to a secure database 610 The disadvantageof using an aggregate method instead of three separate methods can be aloss of some flexibility on the part of a provider and user in thatvarious functions may no longer be independently replaceable.

[1170]FIG. 16 shows methods 1000 as being part of secure database 610.

[1171] A “method” 1000 provided by the preferred embodiment is acollection of basic instructions and information related to the basicinstructions, that provides context, data, requirements and/orrelationships for use in performing, and/or preparing to perform, thebasic instructions in relation to the operation of one or moreelectronic appliances 600. As shown in FIG. 16, methods 1000 in thepreferred embodiment are represented in secure database 610 by:

[1172] method “cores” 1000′;

[1173] Method Data Elements (MDEs) 1202;

[1174] User Data Elements (UDEs) 1200; and

[1175] Data Description Elements (DTDs).

[1176] Method “core” 1000′ in the preferred embodiment may contain orreference one or more data elements such as MDEs 1202 and UDEs 1200. Inthe preferred embodiment. MDEs 1202 and UDEs 1200 may have the samegeneral characteristics, the main difference between these two types ofdata elements being that a UDE is preferably tied to a particular methodas well as a particular user or group of users, whereas an MDE may betied to a particular method but may be user independent. These MDE andUDE data structures 1200, 1202 are used in the preferred embodiment toprovide input data to methods 1000, to receive data outputted bymethods, or both. MDEs 1202 and UDEs 1200 may be delivered independentlyof method cores 1000′ that reference them, or the data structures may bedelivered as part of the method cores. For example, the method core1000′ in the preferred embodiment may contain one or more MDEs 1202and/or UDEs 1200 (or portions thereof). Method core 1000′ may,alternately or in addition, reference one or more MDE and/or UDE datastructures that are delivered independently of method core(s) thatreference them.

[1177] Method cores 1000′ in the preferred embodiment also reference oneor more “load modules” 1100. Load modules 1100 in the preferredembodiment comprise executable code, and may also include or referenceone or more data structures called “data descriptor” (“DTD”)information. This “data descriptor” information may, for example,provide data input information to the DTD interpreter 590. DTDs mayenable load modules 1100 to access e.g. read from and/or write to theMDE and or UDE data elements 1202, 1200.

[1178] Method cores 1000′ may also reference one or more DTD and/or MDEdata structures that contain a textual description of their operationssuitable for inclusion as part of an electronic contract. The referencesto the DTD and MDE data structures may occur in the private header ofthe method core 1000′, or may be specified as part of the event tabledescribed below.

[1179]FIG. 22 shows an example of a format for a method core 1000′provided by the preferred embodiment. A method core 1000′ in thepreferred embodiment contains a method event table 1006 and a methodlocal data area 1008. Method event table 1006 lists “events.” These“events” each reference “load modules” 1100 and/or PERCs 808 thatcontrol processing of an event. Associated with each event in the listis any static data necessary to parameterize the load module 1000 orpermissions record 808, and reference(s) into method user data area 1008that are needed to support that event. The data that parameterizes theload module 1100 can be thought of, in part, as a specific function callto the load module, and the data elements corresponding to it may bethought of as the input and/or output data for that specific functioncall.

[1180] Method cores 1000′ can be specific to a single user, or they maybe shared across a number of users (e.g., depending upon the uniquenessof the method core and/or the specific user data element). Specifically,each user group may have its own UDE 1200 and use a shared method core1000′. This structure allows for lower database overhead than whenassociating an entire method core 1000′ with a user/group. To enable auser to use a method, the user may be sent a method core 1000′specifying a UDE 1200. If that method core 1000′ already exists in thesite's secure database 610, only the UDE 1200 may need to be added.Alternately, the method may create any required UDE 1200 at registrationtime.

[1181] The FIG. 22 example of a format for a method core 1000 providedby the preferred embodiment includes a public (unencrypted) header 802,a private (encrypted) header 804, method event table 1006, and a methodlocal data area 1008.

[1182] An example of a possible field layout for method core 1000′public header 802 is shown in the following table: Field TypeDescription Method ID Creator ID Site ID of creator of this method.Distributor ID Distributor of this method (e.g. last change). Type IDConstant, indicates method ”type.“ Method ID Unique sequence number forthis method. Version ID Version number of this method. Other Class ID IDto support different classification method ”classes.“ information TypeID ID to support method type compatible searching. DescriptiveDescription(s) Textual description(s) of the information method. EventSummary of event classes Summary (e.g., USE) that this method supports.

[1183] An example of a possible field layout for private header 804 isshown below: Field Type Description Copy of Public Header 802 Method IDMethod ID from and ”Other Classification Information“ Public HeaderDescriptive # of Events # of events supported Information in thismethod. Access and Access tag Tags used to Reference Tags determine ifthis method is the Validation tag correct method under management by theSPU; ensure that the method Correlation tag core 1000′ is used onlyunder appropriate circumstances. Data Structure Reference OptionalReference to DTD(s) and/or MDE(s) Check Value Check value for PrivateHeader and method event table. Check Value for Public Header Check Valuefor Public Header

[1184] Referring once again to FIG. 22, method event table 1006 may inthe preferred embodiment include from 1 to N method event records 1012.Each of these method event records 1012 corresponds to a different eventthe method 1000 represented by method core 1000′ may respond to. Methods1000 in the preferred embodiment may have completely different behaviordepending upon the event they respond to. For example, an AUDIT methodmay store information in an audit trail UDE 1200 in response to an eventcorresponding to a user's use of an object or other resource. This sameAUDIT method may report the stored audit trail to a VDE administrator orother participant in response to an administrative event such as, forexample, a timer expiring within a VDE node or a request from anotherVDE participant to report the audit trail. In the preferred embodiment,each of these different events may be represented by an “event code.”This “event code” may be passed as a parameter to a method when themethod is called, and used to “look up” the appropriate method eventrecord 1012 within method event table 1006. The selected method eventrecord 1012, in turn, specifies the appropriate information (e.g., loadmodule(s) 1100, data element UDE(s) and MDE(s) 1200, 1202, and/orPERC(s) 808) used to construct a component assembly 690 for execution inresponse to the event that has occurred.

[1185] Thus, in the preferred embodiment, each method event record 1012may include an event field 1014, a LM/PERC reference field 1016, and anynumber of data reference fields 1018. Event fields 1014 in the preferredembodiment may contain a “event code” or other information identifyingthe corresponding event. The LM/PERC reference field 1016 may provide areference into the secure database 610 (or other “pointer” information)identifying a load module 1100 and/or a PERC 808 providing (orreferencing) executable code to be loaded and executed to perform themethod in response to the event. Data reference fields 1018 may includeinformation referencing a UDE 1200 or a MDE 1202. These data structuresmay be contained in the method local data area 1008 of the method core1000′, or they may be stored within the secure database 610 asindependent deliverables.

[1186] The following table is an example of a possible more detailedfield layout for a method event record 1012: Field Type DescriptionEvent Field 1014 Identifies corresponding event. Access tag Secret tagto grant access to this row of the method event record. LM/PERC DB ID orDatabase reference (or local Reference offset/size pointer). Field 1016Correlation tag Correlation tag to assert when referencing this element.# of Data Element Reference Count of data reference Fields fields in themethod event record. Data UDE ID or Database 610 reference (or Referenceoffset/size local pointer). Field 1 Correlation tag Correlation tag toassert when referencing this element. . . . . . . Data UDE ID orDatabase 610 reference (or Reference offset/size local pointer). Field nCorrelation tag Correlation tag to assert when referencing this element.

[1187] Load Modules

[1188]FIG. 23 is an example of a load module 1100 provided by thepreferred embodiment. In general, load modules 1100 represent acollection of basic functions that are used for control operations.

[1189] Load module 1100 contains code and static data (that isfunctionally the equivalent of code), and is used to perform the basicoperations of VDE 100. Load modules 1100 will generally be shared by allthe control structures for all objects in the system, though proprietaryload modules are also permitted. Load modules 1100 may be passed betweenVDE participants in administrative object structures 870, and areusually stored in secure database 610. They are always encrypted andauthenticated in both of these cases. When a method core 1000′references a load module 1100, a load module is loaded into the SPE 503,decrypted, and then either passed to the electronic appliancemicroprocessor for executing in an HPE 655 (if that is where itexecutes), or kept in the SPE (if that is where it executes). If no SPE503 is present, the load module may be decrypted by the HPE 655 prior toits execution.

[1190] Load module creation by parties is preferably controlled by acertification process or a ring based SPU architecture. Thus, theprocess of creating new load modules 1100 is itself a controlledprocess, as is the process of replacing, updating or deleting loadmodules already stored in a secured database 610.

[1191] A load module 1100 is able to perform its function only whenexecuted in the protected environment of an SPE 503 or an HPE 655because only then can it gain access to the protected elements (e.g.,UDEs 1200, other load modules 1100) on which it operates. Initiation ofload module execution in this environment is strictly controlled by acombination of access tags, validation tags, encryption keys, digitalsignatures and/or correlation tags. Thus, a load module 1100 may only bereferenced if the caller knows its ID and asserts the shared secretcorrelation tag specific to that load module. The decrypting SPU maymatch the identification token and local access tag of a load moduleafter decryption. These techniques make the physical replacement of anyload module 1100 detectable at the next physical access of the loadmodule. Furthermore, load modules 1100 may be made “read only” in thepreferred embodiment. The read-only nature of load modules 1100 preventsthe write-back of load modules that have been tampered with innon-secure space.

[1192] Load modules are not necessarily directly governed by PERCs 808that control them, nor must they contain any time/date information orexpiration dates. The only control consideration in the preferredembodiment is that one or more methods 1000 reference them using acorrelation tag (the value of a protected object created by the loadmodule's owner, distributed to authorized parties for inclusion in theirmethods, and to which access and use is controlled by one or more PERCs808). If a method core 1000 references a load module 1100 and assertsthe proper correlation tag (and the load module satisfies the internaltamper checks for the SPE 503), then that load module can be loaded andexecuted, or it can be acquired from, shipped to, updated, or deletedby, other systems.

[1193] As shown in FIG. 23, load modules 1100 in the preferredembodiment may be constructed of a public (unencrypted) header 802, aprivate (encrypted) header 804, a private body 1106 containing theencrypted executable code, and one or more data description elements(“DTDs”) 1108. The DTDs 1108 may be stored within a load module 1100, orthey may be references to static data elements stored in secure database610.

[1194] The following is an example of a possible field layout for loadmodule public header 802: Field Type Description LM ID VDE ID of LoadModule. Creator ID Site ID of creator of this load module. Type IDConstant indicates load module type. LM ID Unique sequence number forthis load module, which uniquely identifies the load module in asequence of load modules created by an authorized VDE participant.Version ID Version number of this load module. Other Class ID ID tosupport different load classification module classes. information TypeID ID to support method type compatible searching. DescriptiveDescription Textual description of the Information load module.Execution Value that describes what space code execution space (e.g.,SPE or HPE) this load module.

[1195] Many load modules 1100 contain code that executes in an SPE 503.Some load modules 1100 contain code that executes in an HPE 655. Thisallows methods 1000 to execute in whichever environment is appropriate.For example, an INFORMATION method 1000 can be built to execute only inSPE 503 secure space for government classes of security, or in an HPE655 for commercial applications. As described above, the load modulepublic header 802 may contain an “execution space code” field thatindicates where the load module 1100 needs to execute. Thisfunctionality also allows for different SPE instruction sets as well asdifferent user platforms, and allows methods to be constructed withoutdependencies on the underlying load module instruction set.

[1196] Load modules 1100 operate on three major data areas: the stack,load module parameters, and data structures. The stack and executionmemory size required to execute the load module 1100 are preferablydescribed in private header 804, as are the data descriptions from thestack image on load module call, return, and any return data areas. Thestack and dynamic areas are described using the same DTD mechanism. Thefollowing is an example of a possible layout for a load module privateheader 1104: Field Type Description Copy of some or all of informationObject ID from Public Header from public header 802 Other Check ValueCheck Value for Public Header classification information Descriptive LMSize Size of executable code block. Information LM Exec Size Executablecode size for the load module LM Exec Stack Stack size required for theload module Execution space Code that describes the execution code spacefor this load module Access and Access tag Tags used to determine if theload reference tags Validation tag module is the correct LM requested bythe SPE Correlation tag Tag used to determine if the caller of the LMhas the right to execute this LM Digital Signature Used to determine ifthe LM executable content is intact and was created by a trusted source(one with a correct certificate for creating LMs). Data record DTD countNumber of DTDs that follow the descriptor code block information DTD 1reference If locally defined, the physical size and offset in bytes ofthe first DTD defined for this LM. If publicly referenced DTD, this isthe DTD ID and the correlation tag to permit access to the record. ***DTD N reference If locally defined, the physical size and offset inbytes of the Nth DTD defined for this LM. If publicly referenced DTD,this is the DTD ID and the correlation tag to permit access to therecord. Check Value Check Value for entire LM.

[1197] Each load module 1100 also may use DTD 1108 information toprovide the information necessary to support building methods from aload module. This DTD information contains the definition expressed in alanguage such as SGML for the names and data types of all of the methoddata fields that the load module supports, and the acceptable ranges ofvalues that can be placed m the fields Other DTDs may describe thefunction of the load module 1100 in English for inclusion in anelectronic contract, for example.

[1198] The next section of load module 1100 is an encrypted executablebody 1106 that contains one or more blocks of encrypted code. Loadmodules 1100 are preferably coded in the “native” instruction set oftheir execution environment for efficiency and compactness. SPU 500 andplatform providers may provide versions of the standard load modules1100 in order to make their products cooperate with the content indistribution mechanisms contemplated by VDE 100. The preferredembodiment creates and uses native mode load modules 1100 in lieu of aninterpreted or “p-code” solution to optimize the performance of alimited resource SPU. However, when sufficient SPE (or HPE) resourcesexist and/or platforms have sufficient resources, these otherimplementation approaches may improve the cross platform utility of loadmodule code.

[1199] The following is an example of a field layout for a load moduleDTD 1108: Field Type Description DTD ID Uses Object ID from PrivateHeader Creator ID Site ID of creator of this DTD Type ID Constant DTD IDUnique sequence number for this DTD Version ID Version number of thisDTD Descriptive DTD Size Size of DTD block Information Access and Accesstag Tags used to determine if the DTD is reference tags Validation tagthe correct DTD requested by the SPE Correlation tag Tag used todetermine if the caller of this DTD has the right to use the DTD DTDBody DTD Data Definition 1 DTD Data Definition 2 . . . DTD DataDefinition N Check Value Check Value for entire DTD record.

[1200] Some examples of how load modules 1100 may use DTDs 1108 include:

[1201] Increment data element (defined by name in DTD3) value in dataarea DTD4 by value in DTD1

[1202] Set data element (defined by name in DTD3) value in data areaDTD4 to value in DTD3

[1203] Compute atomic element from event in DTD1 from table in DTD3 andreturn in DTD2

[1204] Compute atomic element from event in DTD1 from equation in DTD3and return in DTD2

[1205] Create load module from load module creation template referencedin DTD3

[1206] Modify load module in DTD3 using content in DTD4

[1207] Destroy load module named in DTD3

[1208] Commonly used load modules 1100 may be built into a SPU 500 asspace permits. VDE processes that use built-in load modules 1100 willhave significantly better performance than processes that have to find,load and decrypt external load modules. The most useful load modules1100 to build into a SPU might include scaler meters, fixed price big,budgets and load modules for aggregate methods that perform these threeprocesses.

[1209] User Data Elements (UDEs) 1200 and Method Data Elements (MDEs)1202

[1210] User Data Elements (UDEs) 1200 and Method Data Elements (MDEs)1202 in the preferred embodiment store data. There are many types ofUDEs 1200 and MDEs 1202 provided by the preferred embodiment. In thepreferred embodiment, each of these different types of data structuresshares a common overall format including a common header definition andnaming scheme. Other UDEs 1200 that share this common structure include“local name services records” (to be explained shortly) and accountinformation for connecting to other VDE participants. These elements arenot necessarily associated with an individual user, and may therefore beconsidered MDEs 1202. All UDEs 1200 and all MDEs 1202 provided by thepreferred embodiment may, if desired, (as shown in FIG. 16) be stored ina common physical table within secure database 610, and database accessprocesses may commonly be used to access all of these different types ofdata structures.

[1211] In the preferred embodiment, PERCs 808 and user rights tablerecords are types of UDE 1200. There are many other types of UDEs1200/MDEs 1202, including for example, meters, meter trails, budgets,budget trails, and audit trails. Different formats for these differenttypes of UDEs/MDEs are defined, as described above, by SGML definitionscontained within DTDs 1108. Methods 1000 use these DTDs to appropriatelyaccess UDEs/MDEs 1200, 1202.

[1212] Secure database 610 stores two types of items: static anddynamic. Static data structures and other items are used for informationthat is essentially static information. This includes load modules 1100,PERCs 808, and many components of methods. These items are not updatedfrequently and contain expiration dates that can be used to prevent“old” copies of the information from being substituted for newlyreceived items. These items may be encrypted with a site specific securedatabase file key when they are stored in the secure database 610, andthen decrypted using that key when they are loaded into the SPE.

[1213] Dynamic items are used to support secure items that must beupdated frequently. The UDEs 1200 of many methods must be updated andwritten out of the SPE 503 after each use. Meters and budgets are commonexamples of this. Expiration dates cannot be used effectively to preventsubstitution of the previous copy of a budget UDE 1200. To secure thesefrequently updated items, a transaction tag is generated and included inthe encrypted item each time that item is updated. A list of all VDEitem IDs and the current transaction tag for each item is maintained aspart of the secure database 610.

[1214]FIG. 24 shows an example of a user data element (“UDE”) 1200provided by the preferred embodiment. As shown in FIG. 24, UDE 1200 inthe preferred embodiment includes a public header 802, a private header804. and a data area 1206. The layout for each of these user dataelements 1200 is generally defined by an SGML data definition containedwithin a DTD 1108 associated with one or more load modules 1100 thatoperate on the UDE 1200.

[1215] UDEs 1200 are preferably encrypted using a site specific key oncethey are loaded into a site. This site-specific key masks a validationtag that may be derived from a cryptographically strong pseudo-randomsequence by the SPE 503 and updated each time the record is written backto the secure database 610. This technique provides reasonable assurancethat the UDE 1200 has not been tampered with nor substituted when it isrequested by the system for the next use.

[1216] Meters and budgets are perhaps among the most common datastructures in VDE 100. They are used to count and record events, andalso to limit events. The data structures for each meter and budget aredetermined by the content provider or a distributor/redistributorauthorized to change the information. Meters and budgets, however,generally have common information stored in a common header format(e.g., user ID, site ID and related identification information).

[1217] The content provider or distributor/redistributor may specifydata structures for each meter and budget UDE. Although these datastructures vary depending upon the particular application, some are morecommon than others. The following table lists some of the more commonlyoccurring data structures for METER and BUDGET methods: TypicalDescription or Field type Format Use Use Ascending Use byte, short,long, or Meter/ Ascending count of Counter unsigned versions of Budgetuses the same widths Descending Use byte, short, long, or BudgetDescending count of Counter unsigned versions of permitted use; eg, thesame widths remaining budget Counter/Limit 2, 4 or 8 byte integer Meter/usage limits since a split into two related Budget specific time: bytesor words generally used in compound meter data structures Bitmap Arraybytes Meter/ Bit indicator of use Budget or ownership Wide bitmap Arrayof bytes Meter/ Indicator of use or Budget ownership that may age withtime Last Use Date time_t Meter/ Date of last use Budget Start Datetime_t Budget Date of first allowable use Expiration Date time_t Meter/Expiration Date Budget Last Audit Date time_t Meter/ Date of last auditBudget Next Audit time_t Meter/ Date of next Date Budget required auditAuditor VDE ID Meter/ VDE ID of Budget authorized auditor

[1218] The information in the table above is not complete orcomprehensive, but rather is intended to show some examples of types ofinformation that may be stored in meter and budget related datastructures. The actual structure of particular meters and budgets isdetermined by one or more DTDs 1108 associated with the load modules1100 that create and manipulate the data structure. A list of data typespermitted by the DTD interpreter 590 in VDE 100 is extensible byproperly authorized parties.

[1219]FIG. 25 shows an example of one particularly advantageous kind ofUDE 1200 data area 1206. This data area 1206 defines a “map” that may beused to record usage information. For example, a meter method 1000 maymaintain one or more “usage map” data areas 1206. The usage map may be a“usage bit map” in the sense that it stores one or more bits ofinformation (i.e., a single or multi-dimensional bit image)corresponding to each of several types or categories of usage. Usagemaps are an efficient means for referencing prior usage. For example, ausage map data area may be used by a meter method 1000 to record allapplicable portions of information content that the user has paid touse, thus supporting a very efficient and flexible means for allowingsubsequent user usage of the same portions of the information content.This may enable certain VDE related security functions such as“contiguousness.” “logical relatedness,” randomization of usage, andother usage types. Usage maps may be analyzed for other usage patterns(e.g., quantity discounting, or for enabling a user to reaccessinformation content for which the user previously paid for unlimitedusage).

[1220] The “usage map” concept provided by the preferred embodiment maybe tied to the concept of “atomic elements.” In the preferredembodiment, usage of an object 300 may be metered in terms of “atomicelements.” In the preferred embodiment, an “atomic element” in themetering context defines a unit of usage that is “sufficientlysignificant” to be recorded in a meter. The definition of whatconstitutes an “atomic element” is determined by the creator of anobject 300. For instance, a “byte” of formation content contained in anobject 300 could be defined as an “atomic element,” or a record of adatabase could be defined as an “atomic element,” or each chapter of anelectronically published book could be defined as an “atomic element.”

[1221] An object 300 can have multiple sets of overlapping atomicelements. For example, an access to any database in a plurality ofdatabases may be defined as an “atomic element.” Simultaneously, anaccess to any record, field of records, sectors of informations, and/orbytes contained in any of the plurality of databases might also bedefined as an “atomic element.” In an electronically publishednewspaper, each hundred words of an article could be defined as an“atomic element,” while articles of more than a certain length could bedefined as another set of “atomic elements.” Some portions of anewspaper (e.g., advertisements, the classified section, etc.) might notbe mapped into an atomic element.

[1222] The preferred embodiment provides an essentially unboundedability for the object creator to define atomic element types. Suchatomic element definitions may be very flexible to accommodate a widevariety of different content usage. Some examples of atomic elementtypes supported by the preferred embodiment include bytes, records,files, sectors, objects, a quantity of bytes, contiguous or relativelycontiguous bytes (or other predefined unit types), logically relatedbytes containing content that has some logical relationship by topic,location or other user specifiable logic of relationship, etc. Contentcreators preferably may flexibly define other types of atomic elements.

[1223] The preferred embodiment of the present invention provides EVENTmethods to provide a mapping between usage events and atomic elements.Generally, there may be an EVENT method for each different set of atomicelements defined for an object 300. In many cases, an object 300 willhave at least one type of atomic element for metering relating tobilling, and at least one other atomic element type for non-billingrelated metering (e.g., used to, for example, detect fraud, billadvertisers, and/or collect data on end user usage activities).

[1224] In the preferred embodiment, each EVENT method in a usage relatedcontext performs two functions: (1) it maps an accessed event into a setof zero or more atomic elements, and (2) it provides information to oneor more METER methods for metering object usage. The definition used todefine this mapping between access events and atomic elements may be inthe form of a mathematical definition, a table, a load module, etc. Whenan EVENT method maps an access request into “zero” atomic elements, auser accessed event is not mapped into any atomic element based on theparticular atomic element definition that applies This can be, forexample, the object owner is not interested in metering usage based onsuch accesses (e.g., because the object owner deems such accesses to beinsignificant from a metering standpoint).

[1225] A “usage map” may employ a “bit map image” for storage of usagehistory information in a highly efficient manner. Individual storageelements in a usage map may correspond to atomic elements. Differentelements within a usage map may correspond to different atomic elements(e.g., one map element may correspond to number of bytes read, anothermap element may correspond to whether or not a particular chapter wasopened, and yet another map element may correspond to some other usageevent).

[1226] One of the characteristics of a usage map provided by thepreferred embodiment of the present invention is that the significanceof a map element is specified, at least in part, by the position of theelement within the usage map. Thus, in a usage map provided by thepreferred embodiment, the information indicated or encoded by a mapelement is a function of its position (either physically or logically)within the map structure. As one simple example, a usage map for atwelve-chapter novel could consist of twelve elements, one for eachchapter of the novel. When the user opens the first chapter, one or morebits within the element corresponding to the first chapter could bechanged in value (e.g., set to “one”). In this simple example where theowner of the content object containing the novel was interested only inmetering which chapters had been opened by the user, the usage mapelement corresponding to a chapter could be set to “one” the first timethe user opened that corresponding chapter, and could remain “one” nomatter how many additional times the user opened the chapter. The objectowner or other interested VDE participant would be able to rapidly andefficiently tell which chapter(s) had been opened by the user simply byexamining the compact usage map to determine which elements were set to“one.”

[1227] Suppose that the content object owner wanted to know how manytimes the user had opened each chapter of the novel In this case, theusage map might comprise, for a twelve-chapter novel, twelve elementseach of which has a one-to-one correspondence with a different one ofthe twelve chapters of the novel. Each time a user opens a particularchapter, the corresponding METER method might increment the valuecontained in the corresponding usage map element In this way, an accountcould be readily maintained for each of the chapters of the novel.

[1228] The position of elements within a usage map may encode amulti-variable function. For example, the elements within a usage mapmay be arranged in a two-dimensional array as shown in FIG. 25B.Different array coordinates could correspond to independent variablessuch as, for example, atomic elements and time. Suppose, as an example,that a content object owner distributes an object containing acollection of audio recordings. Assume further that the content objectowner wants to track the number of times the user listens to eachrecording within the collection, and also wants to track usage based onmonth of the year. Thus, assume that the content object owner wishes toknow how many times the user during the month of January listened toeach of the recordings on a recording-by-recording basis, similarlywants to know this same information for the month of February, March,etc. In this case, the usage map (see FIG. 25B) might be defined as atwo-dimensional array of elements. One dimension of the array mightencode audio recording number. The other dimension of the array mightencode month of the year. During the month of January, the correspondingMETER method would increment elements in the array in the “January”column of the array, selecting which element to increment as a functionof recording number When January comes to an end, the METER method mightcease writing into the array elements in the January column, and insteadwrite values into a further set of February array elements—once againselecting the particular array element in this column as a function ofrecording number. This concept may be extended to N dimensions encodingN different variables.

[1229] Usage map meters are thus an efficient means for referencingprior usage. They may be used to enable certain VDE related securityfunctions such as testing for contiguousness (including relativecontiguousness), logical relatedness (including relative logicalrelatedness), usage randomization, and other usage patterns. Forexample, the degree or character of the “randomness” of content usage bya user might serve as a potential indicator of attempts to circumventVDE content budget limitations. A user or groups of users might employmultiple sessions to extract content in a manner which does not violatecontiguousness, logical relatedness or quantity limitations, but whichnevertheless enables reconstruction of a material portion or all of agiven, valuable unit of content. Usage maps can be analyzed to determineother patterns of usage for pricing such as, for example, quantitydiscounting after usage of a certain quantity of any or certain atomicunits, or for enabling a user to reaccess an object for which the userpreviously paid for unlimited accesses (or unlimited accesses over acertain time duration). Other useful analyses might include discountingfor a given atomic unit for a plurality of uses.

[1230] A further example of a map meter includes storing a record of allapplicable atomic elements that the user has paid to use (oralternatively, has been metered as having used, though payment may notyet have been required or made). Such a usage map would support a veryefficient and flexible way to allow subsequent user usage of the sameatomic elements.

[1231] A further usage map could be maintained to detect fraudulentusage of the same object. For example, the object might be stored insuch a way that sequential access of long blocks should never occur. AMETER method could then record all applicable atomic elements accessesduring, for example, any specified increment of time, such as tenminutes, an hour, a day, a month, a year, or other time duration). Theusage map could be analyzed at the end of the specified time incrementto check for an excessively long contiguous set of accessed blocks,and/or could be analyzed at the initiation of each access to applicableatomic elements. After each time duration based analysis, if nofraudulent use is detected, the usage map could be cleared (or partiallycleared) and the mapping process could begin in whole or in part anew.If a fraudulent use pattern is suspected or detected, that informationmight be recorded and the use of the object could be halted. Forexample, the user might be required to contact a content provider whomight then further analyze the usage information to determine whether ornot further access should be permitted.

[1232]FIG. 25c shows a particular type of “wide bit map” usage record1206 wherein each entry in the usage record corresponds to usage duringa particular time period (e.g., current month usage, last month's usage,usage in the month before last, etc.). The usage record shown thuscomprises an array of “flags” or fields 1206, each element in the arraybeing used to indicate usage in a different time period in thisparticular example. When a time period ends, all elements 1206 in thearray may be shifted one position, and thus usage information (or thepurchase of user access rights) over a series of time periods can bereflected by a series of successive array elements. In the specificexample shown in FIG. 25c, the entire wide array 1206 is shifted by onearray position each month, with the oldest array element being deletedand the new array element being “turned” in a new array mapcorresponding to the current time period In this example, record 1302tracks usage access rights and/or other usage related activities duringthe present calendar month as well for the five immediately priorcalendar months. Corresponding billing and/or billing method 406 mayinspect the map, determine usage as related to billing and/or securitymonitoring for current usage based on a formula that employs the usagedata stored in the record, and updates the wide record to indicate theapplicable array elements for which usage occurred or the like. A widebit map may also be used for many other purposes such as maintaining anelement by element count of usage, or the contiguousness, relatedness,etc. function described above, or some combination of functionality.

[1233] Audit trail maps may be generated at any frequency determined bycontrol, meter, budget and billing methods and load modules associatedwith those methods. Audit trails have a similar structure to meters andbudgets and they may contain user specific information in addition toinformation about the usage event that caused them to be created. Likemeters and budgets, audit trails have a dynamic format that is definedby the content provider or their authorized designee, and share thebasic element types for meters and budgets shown in the table above. Inaddition to these types, the following table lists some examples ofother significant data fields that may be found in audit trails Fieldtype Format Typical Use Description of Use Use Event ID unsigned longMeter/Budget/ Event ID that started a Billing processing sequenceInternal unsigned long Meter/Budget/ Transaction number to SequenceBilling help detect audits that Number have been tampered with. AtomicUnsigned Meter/Billing Atomic element(s) and Element(s) integer(s) of IDof object that was & Object ID appropriate used width Personal UserCharacter or Budget Billing Personal information Information other aboutuser information Use Date/time time_t Meter/Budget Date/time of useBilling Site ID/User VDE ID Meter/Budget VDE ID of user ID Billing

[1234] Audit trail records may be automatically combined into singlerecords to conserve header space. The combination process may, forexample, occur under control of a load module that creates individualaudit trail records.

[1235] Permissions Record Overview

[1236]FIG. 16 also shows that PERCs 808 may be stored as part of securedatabase 610 Permissions records (“PERCs”) 808 are at the highest levelof the data driven control hierarchy provided by the preferredembodiment of VDE 100. Basically, there is at least one PERC 808 thatcorresponds to each information and or transactional content distributedby VDE 100. Thus, at least one PERC 808 exists for each VDE object 300in the preferred embodiment. Some objects may have multiplecorresponding PERCs 808. PERC 808 controls how access and/ormanipulation permissions are distributed and/or how content and/or otherinformation may otherwise be used. PERC 808 also specifies the “rights”of each VDE participant in and to the content and/or other information.

[1237] In the preferred embodiment, no end user may use or access a VDEobject unless a permissions record 808 has been delivered to the enduser. As discussed above, a PERC 808 may be delivered as part of atraveling object 860 or it may be delivered separately (for example,within an administrative object). An electronic appliance 600 may notaccess an object unless a corresponding PERC 808 is present, and mayonly use the object and related information as permitted by the controlstructures contained within the PERC.

[1238] Briefly, the PERC 808 stores information concerning the methods,method options, decryption keys and rights with respect to acorresponding ODE object 300

[1239] PERC 808 includes control structures that define high levelcategories or classifications of operations. These high level categoriesare referred to as “rights.” The “right” control structures, in turn,provide internal control structures that reference “methods” 1000. Theinternal structure of preferred embodiment PERC 808 organizes the“methods” that are required to perform each allowable operation on anobject or associated control structure (including operations performedon the PERC itself). For example, PERC 808 contains decryption keys forthe object, and usage of the keys is controlled by the methods that arerequired by the PERC for performing operations associated with theexercise of a “right.”

[1240] PERC 808 for an object is typically created when the object iscreated, and future substantive modifications of a PERC, if allowed, arecontrolled by methods associated with operations using the distributionright(s) defined by the same (or different PERC.

[1241]FIG. 22 shows the internal structures present in an example of aPERC 808 provided by the preferred embodiment. All of the structuresshown represent (or reference) collections of methods required toprocess a corresponding object in some specific way. PERCs 808 areorganized as a hierarchical structure, and the basic elements of thehierarchy are as follows:

[1242] “rights” records 906

[1243] “control sets” 914

[1244] “required method” records 920 and

[1245] “required method options” 924.

[1246] There are other elements that may be included in a PERC 808hierarchy that describe rules and the rule options to support thenegotiation of rule sets and control information for smart objects andfor the protection of a user's personal information by a privacy filter.These alternate elements may include:

[1247] optional rights records

[1248] optional control sets

[1249] optional method records

[1250] permitted rights records

[1251] permitted rights control sets

[1252] permitted method records

[1253] required DTD descriptions

[1254] optional DTD descriptions

[1255] permitted DTD descriptions

[1256] These alternate fields can control other processes that may, inpart, base negotiations or decisions regarding their operation on thecontents of these fields. Rights negotiation, smart object controlinformation, and related processes can use these fields for more precisecontrol of their operation.

[1257] The PERC 808 shown in FIG. 26 includes a PERC header 900, a CSO(“control set 0”) 902, private body keys 904, and one or more rightssub-records 906. Control set 0 902 in the preferred embodiment containsinformation that is common to one or more “rights” associated with anobject 300. For example, a particular “event” method or methods might bethe same for usage rights, extraction rights and/or other rights. Inthat case, “control set 0” 902 may reference this event that is commonacross multiple “rights.” The provision of “control set 0” 902 isactually an optimization, since it would be possible to store differentinstances of a commonly-used event within each of plural “rights”records 906 of a PERC 808.

[1258] Each rights record 906 defines a different “right” correspondingto an object. A “right” record 906 is the highest level of organizationpresent in PERC 808. There can be several different rights in a PERC808. A “right” represents a major functional partitioning desired by aparticipant of the basic architecture of VDE 100. For example, the rightto use an object and the right to distribute rights to use an object aremajor functional groupings within VDE 100. Some examples of possiblerights include access to content, permission to distribute rights toaccess content, the ability to read and process audit trails related tocontent and/or control structures, the right to perform transactionsthat may or may not be related to content and/or related controlstructures (such as banking transactions, catalog purchases, thecollection of taxes, EDI transactions, and such), and the ability tochange some or all of the internal structure of PERCs created fordistribution to other users. PERC 808 contains a rights record 906 foreach type of right to object access/use the PERC grants.

[1259] Normally, for VDE end users, the most frequently granted right isa usage right. Other types of rights include the “extraction right,” the“audit right” for accessing audit trail information of end users, and a“distribution right” to distribute an object. Each of these differenttypes of rights may be embodied in a different rights record 906 (oralternatively, different PERCs 808 corresponding to an object may beused to grant different rights).

[1260] Each rights record 906 includes a rights record header 908, a CSR(“control set for right”, 910, one or more “right keys” 912, and one ormore “control sets” 914. Each “nights” record 906 contains one or morecontrol sets 914 that are either required or selectable options tocontrol an object in the exercise of that “right.” Thus, at the nextlevel, inside of a “right” 906, are control sets 914. Control sets 914,in turn, each includes a control set header 916, a control method 918,and one or more required methods records 920. Required methods records920, in turn, each includes a required method header 922 and one or morerequired method options 924.

[1261] Control sets 914 exist in two types in VDE 100: common requiredcontrol sets which are given designations “control set 0” or “controlset for right,” and a set of control set options. “Control set 0” 902contains a list of required methods that are common to all control setoptions, so that the common required methods do not have to beduplicated in each control set option. A “control set for right” (“CSR”)910 contains a similar list for control sets within a given right.“Control set 0” and any “control sets for rights” are thus, as mentionedabove, optimizations; the same functionality for the control sets can beaccomplished by listing all the common required methods in each controlset option and omitting “control set 0” and any “control sets forrights.”

[1262] One of the control set options. “control set 0” and theappropriate “control set for right” together form a complete control setnecessary to exercise a right.

[1263] Each control set option contains a list of required methods 1000and represents a different way the right may be exercised. Only one ofthe possible complete control sets 914 is used at any one time toexercise a right in the preferred embodiment.

[1264] Each control set 914 contains as many required methods records920 as necessary to satisfy all of the requirements of the creatorsand/or distributors for the exercise of a right. Multiple ways a rightmay be exercised, or multiple control sets that govern how a given rightis exercised, are both supported. As an example, a single control set914 might require multiple meter and budget methods for reading theobject's content, and also require different meter and budget methodsfor printing an object's content. Both reading and printing an object'scontent can be controlled in a single control set 914.

[1265] Alternatively, two different control set options could supportreading an object's content by using one control set option to supportmetering and budgeting the number of bytes read, and the other controlset option to support metering and budgeting the number of paragraphsread. One or the other of these options would be active at a time

[1266] Typically, each control set 914 will reference a set of relatedmethods, and thus different control sets can offer a different set ofmethod options. For example, one control set 914 may represent onedistinct kind of metering methodology, and another control set mayrepresent another, entirely different distinct metering methodology.

[1267] At the next level inside a control set 914 are the requiredmethods records 920. Methods records 920 contain or reference methods1000 in the preferred embodiment. Methods 1000 are a collection of“events,” references to load modules associated with these events,static data, and references to a secure database 610 for automaticretrieval of any other separately deliverable data elements that may berequired for processing events (e.g., UDEs). A control set 914 containsa list of required methods that must be used to exercise a specificright (i.e., process events associated with a right). A required methodrecord 920 listed in a control set 914 indicates that a method mustexist to exercise the right that the control set supports. The requiredmethods may reference “load modules” 1100 to be discussed below Briefly,load modules 1100 are pieces of executable code that may be used tocarry out required methods

[1268] Each control set 914 may have a control method record 918 as oneof Its required methods. The referenced control method may define therelationships between some or all of the various methods 1000 defined bya control set 906. For example, a control method may indicate whichrequired methods are functionally grouped together to process particularevents, and the order for processing the required methods. Thus, acontrol method may specify that required method referenced by record920(a)(1)(i) is the first to be called and then its output is to go torequired method referenced by record 920(a)(1)(ii) and so on. In thisway, a meter method may be tied to one or more billing methods and thenthe billing methods may be individually tied to different budgetmethods, etc.

[1269] Required method records 920 specify one or more required methodoptions 924. Required method options are the lowest level of controlstructure in a preferred embodiment PERC 808. By parameterizing therequired methods and specifying the required method options 924independently of the required methods, it becomes possible to reuserequired methods in mans different circumstances.

[1270] For example, a required method record 920 may indicate that anactual budget method ID must be chosen from the list of budget methodIDs in the required method option list for that required method.Required method record 920 in this case does not contain any method IDsfor information about the type of method required, it only indicatesthat a method is required. Required method option 924 contains themethod D of the method to be used if this required method option isselected. As a further optimization, an actual method ID may be storedif only one option exists for a specific required method. This allowsthe size of this data structure to be decreased.

[1271] PERC 808 also contains the fundamental decryption keys for anobject 300, and any other keys used with “rights” (for encoding and/ordecoding audit trails, for example). It may contain the keys for theobject content or keys to decrypt portions of the object that containother keys that then can be used to decrypt the content of the object.Usage of the keys is controlled by the control sets 914 in the same“right” 906 with=PERC 808.

[1272] In more detail, FIG. 26 shows PERC 808 as including private bodykeys 904, and right keys 912. Private body keys 904 are used to decryptinformation contained within a private body 806 of a corresponding VDEobject 300 Such information may include, for example, methods 1000, loadmodules 1100 and/or UDEs 1200, for example. Right keys 912 are keys usedto exercise a right in the preferred embodiment. Such right keys 912 mayinclude, for example, decryption keys that enable a method specified byPERC 808 to decrypt content for release by a VDE node to an end user.These right keys 912 are, in the preferred embodiment, unique to anobject 300. Their usage is preferably controlled by budgets in thepreferred embodiment.

[1273] Detailed Example of a PERC 808

[1274]FIGS. 26A and 26B show one example of a preferred embodiment PERC808. In this example, PERC header 900 includes:

[1275] a site record number 926,

[1276] a field 928 specifying the length of the private body key block,

[1277] a field 930 specifying the length of the PERC,

[1278] an expiration date/time field 932 specifying the expiration dateand/or time for the PERC,

[1279] a last modification date/time field 934 specifying the last dateand/or time the PERC 808 was modified.

[1280] the original distributor ID field 936 that specifies whooriginally distributed the PERC and/or corresponding object,

[1281] a last distributor field 938 that specifies who was the lastdistributor of the PERC and/or the object,

[1282] an object ID field 940 identifying the corresponding VDE object300,

[1283] a field 942 that specifies the class and/or type of PERC and/orthe instance ID for the record class to differentiate the PERCs of thesame type that may differ in their particulars,

[1284] a field 944 specifying the number of “rights” sub-records 906within the PERC, and

[1285] a validation tag 948.

[1286] The PERC 808 shown in FIGS. 26a, 26 b also has private body keysstored in a private body key block 950.

[1287] This PERC 808 includes a control set 0 sub-record 914(0) that maybe used commonly by all of rights 906 within the PERC. This control set0 record 914(0) may include the following fields:

[1288] a length field 952 specifying the length of the control set 0record

[1289] a field 954 specifying the number of required method records 920within the control set

[1290] an access tag field 956 specifying an access tag to controlmodification of the record and

[1291] one or more required method records 920.

[1292] Each required method record 920, in turn may include:

[1293] a length field 958 specifying the length of the required methodrecord

[1294] a field 960 specifying the number of method option records withinthe required method record 920

[1295] an access tag field 962 specifying an access tag to controlmodification of the record and

[1296] one or more method option records 924.

[1297] Each method option sub-record 924 may include:

[1298] a length field 964 specifying the length of the method optionrecord

[1299] a length field 966 specifying the length of the data area (ifany) corresponding to the method option record

[1300] a method ID field 968 specifying a method ID (e.g.,type/owner/class/instance)

[1301] a correlation tag field 970 specifying a correlation tag forcorrelating with the method specified in field 968

[1302] an access tag field 972 specifying an access tag to controlmodification of this record

[1303] a method-specific attributes field 974

[1304] a data area 976 and

[1305] a check value field 978 for validation purposes

[1306] In this example of PERC 808 also includes one or more rightsrecords 906, and an overall check value field 980. FIG. 23b is anexample of one of right records 906 shown in FIG. 16a. In thisparticular example, rights record 906 a includes a rights record header908 comprising:

[1307] a length field 982 specifying the length of the rights key block912

[1308] a length field 984 specifying the length of the rights record 908

[1309] an expiration date/time field 986 specifying the expiration dateand/or time for the rights record

[1310] a right ID field 988 identifying a right

[1311] a number field 990 specifying the number of control sets 914within the rights record 906, and

[1312] an access tag field 992 specifying an access tag to controlmodification of the right record.

[1313] This example of rights record 906 includes

[1314] a control set for this right (CSR) 910

[1315] a rights key block 912

[1316] one or more control sets 914, and

[1317] a check value field 994

[1318] Object Registry

[1319] Referring once again to FIG. 16, secure database 610 providesdata structures that support a “lookup” mechanism for “registered”objects. This “lookup” mechanism permits electronic appliance 600 toassociate, in a secure way, VDE objects 300 with PERCs 808, methods 1000and load modules 1100. In the preferred embodiment, this lookupmechanism is based in part on data structures contained within objectregistry 450.

[1320] In one embodiment, object registry 450 includes the followingtables:

[1321] an object registration table 460;

[1322] a subject table 462;

[1323] a User Rights Table (“URT”) 464;

[1324] an Administrative Event Log 442;

[1325] a shipping table 444; and

[1326] a receiving table 446

[1327] Object registry 460 in the example embodiment is a database ofinformation concerning registered VDE objects 300 and the rights ofusers and user groups with regard to those objects. When electronicappliance 600 receives an object 300 containing a new budget or loadmodule 1100, the electronic appliance usually needs to add theinformation contained by the object to secure database 610. Moreover,when any new VDE object 300 arrives at an electronic appliance 600, theelectronic appliance must “register” the object within object registry450 so that it can be accessed. The lists and records for a new object300 are built in the preferred embodiment when the object is“registered” by the electronic appliance 600. The information for theobject may be obtained from the object's encrypted private header,object body, and encrypted name services record. This information may beextracted or derived from the object 300 by SPE 503, and then storedwithin secure database 610 as encrypted records.

[1328] In one embodiment, object registration table 460 includesinformation identifying objects within object storage repository 728.These VDE objects 300 stored within object storage 728 are not, in theexample embodiment, necessarily part of secure database 610 since theobjects typically incorporate their own security (as necessary andrequired) and are maintained using different mechanisms than the onesused to maintain the secure database Even though VDE objects 300 may notstrictly be part of secure database 610, object registry 450 (and inparticular, object registration table 460) refers to the objects andthus “incorporates them by reference” into the secure database. In thepreferred embodiment, an electronic appliance 600 may be disabled fromusing any VDE object 300 that has not been appropriately registered witha corresponding registration record stored within object registrationtable 460.

[1329] Subject table 462 in the example embodiment establishescorrespondence between objects referred to by object registration table460 and users (or groups of users) of electronic appliance 600. Subjecttable 462 provides many of the attributes of an access control list(“ACL”), as will be explained below.

[1330] User rights table 464 in the example embodiment providespermissioning and other information specific to particular users orgroups of users and object combinations set forth in subject table 462.In the example embodiment, permissions records 808 (also shown in FIG.16 and being stored within secure database 610) may provide a universeof permissioning for a particular object-user combination. Recordswithin user rights table 464 may specify a sub-set of this permissioninguniverse based on, for example, choices made by users during interactionat time of object registration.

[1331] Administrative event log 442, shipping table 444, and receivingtable 446 provide information about receipts and deliveries of VDEobjects 300. These data structures keep track of administrative objectssent or received by electronic appliance 600 including, for example, thepurpose and actions of the administrative objects in summary anddetailed form. Briefly, shipping table 444 incudes a shipping record foreach administrative object sent (or scheduled to be sent) by electronicappliance 600 to another VDE participant. Receiving table 446 in thepreferred embodiment includes a receiving record for each administrativeobject received (or scheduled to be received) by electronic appliance600. Administrative event log 442 includes an event log record for eachshipped and each received administrative object, and may include detailsconcerning each distinct event specified by received administrativeobjects.

[1332] Administrative Object Shipping and Receiving

[1333]FIG. 27 is an example of a detailed format for a shipping table444. In the preferred embodiment, shipping table 444 includes a header444A and any number of shipping records 445 Header 444A includesinformation used to maintain shipping table 444 Each shipping record 445within shipping table 444 provides details concerning a shipping eventi.e., either a completed shipment of an administrative object to anotherVDE participant, or a scheduled shipment of an administrative object.

[1334] In the example embodiment of the secure database 610, shippingtable header 444A may include a site record number 444A(1), a user (orgroup) ID 444A(2), a series of reference fields 444A(3)-444(6),validation tags 444A(7)-444A(8), and a check value field 444A(9). Thefields 444A(3)-444A(6) reference certain recent IDs that designate listsof shipping records 445 within shipping table 444. For example, field444A(3) may reference to a “first” shipping record representing acompleted outgoing shipment of an administrative object, and field444A(4) may reference to a “last” shipping record representing acompleted outgoing shipment of an administrative object. In thisexample, “first” and “last” may, if desired, refer to time or order ofshipment as one example. Similarly, fields 444(5) and 444,(6) mayreference to “first” and “last” shipping records for scheduled outgoingshipments. Validation tag 444A(7) may provide validation from a nameservices record within name services record table 452 associated withthe user (group) ID in the header. This permits access from the shippingrecord back to the name services record that describes the sender of theobject described by the shipping records. Validation tag 444A(8)provides validation for a “first” outgoing shipping record referenced byone or more of pointers 444A(3)-444A(6). Other validation tags may beprovided for validation of scheduled shipping record(s).

[1335] Shipping record 444(1) shown includes a site record number445(1)(A). It also includes first and last scheduled shipment date/times445(1),(B) 445(1)(C) providing a window of time used for schedulingadministrative object shipments. Field 445(1)(D) may specify an actualdate/time of a completed shipment of an administrative object. Field445(1)(E) provides an ID of an administrative object shipped or to beshipped, and thus identifies which administrative object within objectstorage 728 pertains to this particular shipping record. A referencefield 445(1)(G) references a name services record within name servicesrecord table 452 specifying the actual or intended recipient of theadministrative object shipped or to be shipped. This information withinname services record table 452 may, for example, provide routinginformation sufficient to permit outgoing administrative objects manager754 shown in FIG. 12 to inform object switch 734 to ship theadministrative object to the intended recipient A field 445(1)(H) mayspecify (e.g., using a series of bit flags) the purpose of theadministrative object shipment, and a field 445(1)(I) may specify thestatus of the shipment. Reference fields 445(1)(J), 445(1)(K) mayreference “previous” and “next” shipping records 445 in a linked list inthe preferred embodiment, there may be two linked lists, one forcompleted shipping records and the other for scheduled shippingrecords). Fields 445(1)(L)-445(1)(P) may provide validation tagsrespectively from header 444A, to a record within administrative eventlog 442 pointed to by pointer 445(1)(F); to the name services recordreferenced by field 445(1)(G); from the previous record referenced by445(1)(J): and to the next record referenced by field 445(1)(K). A checkvalue field 445(1)(Q) may be used for validating shipping record 445.

[1336]FIG. 28 shows an example of one possible detailed format for areceiving table 446. In one embodiment, receiving table 446 has astructure that is similar to the structure of the shipping table 444shown in FIG. 27. Thus, for example, receiving table 446 may include aheader 446 a and a plurality of receiving records 447, each receivingrecord including details about a particular reception or scheduledreception of an administrative object. Receiving table 446 may includetwo linked lists, one for completed receptions and another for schedulereceptions. Receiving table records 447 may each reference an entrywithin name services record table 452 specifying an administrativeobject sender, and may each point to an entry within administrativeevent log 442. Receiving records 447 may also include additional detailsabout scheduled and or completed reception (e.g., scheduled or actualdate/time of reception, purpose of reception and status of reception),and they may each include validation tags for validating references toother secure database records.

[1337]FIG. 29 shows an example of a detailed format for anadministrative event log 442. In the preferred embodiment,administrative event log 442 includes an event log record 442(1) . . .442(N) for each shipped administrative object and for each receivedadministrative object. Each administrative event log record may includea header 443 a and from 1 to N sub-records 442(J)(1) . . . 442(J)(N). Inthe preferred embodiment, header 443 a may include a site record numberfield 443A(1), a record length field 443A(2), an administrative objectID field 443A(3), a field 443A(4) specifying a number of events, avalidation tag 443A(5) from shipping table 444 or receiving table 446,and a check sum field 443A(6). The number of events specified in field443A(4) corresponds to the number of sub-records 442(J)(1) . . .442(J)(N) within the administrative event log record 442(J). Each ofthese sub-records specifies information about a particular “event”affected or corresponding to the administrative object specified withinfield 443(A)(3). Administrative events are retained in theadministrative event log 442 to permit the reconstruction (andpreparation for construction or processing) of the administrativeobjects that have been sent from or received by the system. This permitslost administrative objects to be reconstructed at a later time.

[1338] Each sub-record may include a sub-record length field442(J)(1)(a), a data area length field 442(J)(1)(b), an event ID field442(J)(1)(c), a record type field 442(J)(1)(d), a record ID field442(J)(1)(e), a data area field 442(J)(1)(f), and a check value field442(J)(1)(g). The data area 442(J)(1)(f) may be used to indicate whichinformation within secure database 610 is affected by the eventspecified in the event ID field 442(J)(1)(c), or what new securedatabase item(s) were added, and may also specify the outcome of theevent.

[1339] The object registration table 460 in the preferred embodimentincludes a record corresponding to each VDE object 300 within objectstorage (repository) 728. When a new object arrives or is detected(e.g., by redirector 684), a preferred embodiment electronic appliance600 “registers” the object by creating an appropriate objectregistration record and storing it in the object registration table 460In the preferred embodiment, the object registration table storesinformation that is user-independent, and depends only on the objectsthat are registered at a given ODE electronic appliance 600.Registration activities are typically managed by a REGISTER methodassociated with an object.

[1340] In the example, subject table 462 associates users (or groups ofusers) with registered objects. The example subject table 462 performsthe function of an access control list by specifying which users areauthorized to access which registered VDE objects 300.

[1341] As described above, secure database 610 stores at least one PERC808 corresponding to each registered VDE object 300. PERCS 808 specify aset of rights that may be exercised to use or access the correspondingVDE object 300. The preferred embodiment allows user to “customize”their access rights by selecting a subset of rights authorized by acorresponding PERC 808 and/or by specifying parameters or choices thatcorrespond to some or all of the rights granted by PERC 808. These userchoices are set forth in a user rights table 464 in the preferredembodiment. User rights table (URT) 464 includes URT records, each ofwhich corresponds to a user (or group of users). Each of these URTrecords speckles user choices for a corresponding VDE object 300 Theseuser choices may, either independently or in combination with a PERC808, reference one or more methods 1000 for exercising the rightsgranted to the user by the PERC 808 in a way specified by the choicescontained within the URT record.

[1342]FIG. 30 shows an example of how these various tables may interactwith one another to provide a secure database lookup mechanism. FIG. 30shows object registration table 460 as having a plurality of objectregistration records 460(1), 460(2), . . . . These records correspond toVDE objects 300(1), 300(2), . . . stored within object repository 728.FIG. 31 shows an example format for an object registration record 460provided by the preferred embodiment. Object registration record 460(N)may include the following fields:

[1343] site record number field 466(1)

[1344] object type field 466(2)

[1345] creator ID field 466(3)

[1346] object ID field 466(4)

[1347] a reference field 466(5) that references subject table 462

[1348] an attribute field 466(6)

[1349] a minimum registration interval field 466(7)

[1350] a tag 466(8) to a subject table record, and

[1351] a check value field 466(9).

[1352] The site record number field 466(1) specifies the site recordnumber for this object registration record 460(N). In one embodiment ofsecure database 610, each record stored within the secure database isidentified by a site record number. This site record number may be usedas part of a database lookup process in order to keep track of all ofthe records within the secure database 610.

[1353] Object type field 466(2) may specify the type of registered VDEobject 300 (e.g., a content object, an administrative object, etc.).

[1354] Creator ID field 466(3) in the example may identify the creatorof the corresponding VDE object 300.

[1355] Object ID field 466(4) in the example uniquely identifies theregistered VDE object 300.

[1356] Reference field 466(5) in the preferred embodiment identifies arecord within the subject table 462. Through use of this reference,electronic appliance 600 may determine all users (or user groups listedin subject table 462 authorized to access the corresponding VDE object300. Tag 466(8) is used to validate that the subject table recordsaccessed using field 466(5) is the proper record to be used with theobject registration record 460(N)

[1357] Attribute field 466(6) may store one or more attributes orattribute flags corresponding to VDE object 300.

[1358] Minimum registration interval field 466(7) may specify how oftenthe end user may re-register as a user of the VDE object 300 with aclearinghouse service, VDE administrator, or VDE provider. One reason toprevent frequent re-registration is to foreclose users from reusingbudget quantities in traveling objects until a specified amount of timehas elapsed. The minimum registration interval field 466(7) may be leftunused when the object owner does not wish to restrict re-registration.

[1359] Check value field 466(9) contains validation information used fordetecting corruption or modification of record 460(N) to ensure securityand integrity of the record. In the preferred embodiment, many or all ofthe fields within record 460(N) (as with other records within the securedatabase 610) may be fully or partially encrypted and/or contain fieldsthat are stored redundantly in each record (once in unencrypted form andonce in encrypted form). Encrypted and unencrypted versions of the samefields may be cross checked at various times to detect corruption ormodification of the records.

[1360] As mentioned above, reference field 466(5) references subjecttable 462, and in particular, references one or more user/object records460(M) within the subject table. FIG. 32 shows an example of a formatfor a user/object record 462(M) provided by the example. Record 462(M)may include a header 468 and a subject record portion 470. Header 468may include a field 468(6) referencing a “first” subject record 470contained within the subject registration table 462. This “first”subject record 470(1) may, in turn, include a reference field 470(5)that references a “next” subject record 470(2) within the subjectregistration table 462, and so on. This “linked list” structure permitsa single object registration record 460(N) to reference to from one to Nsubject records 470.

[1361] Subject registration table header 468 in the example includes asite record number field 468(1) that may uniquely identify the header asa record within secure database 610 Header 468 may also include acreator ID field 468(2) that may be a copy of the content of the objectregistration table creator ID field 466(3) Similarly, subjectregistration table header 468 may include an object ID field 468(5) thatmay be a copy of object ID field 466(4) within object registration table460. These fields 468(2), 468(5) make user object registration recordsexplicitly correspond to particular VDE objects 300

[1362] Header 468 may also include a tag 468(7) that permits validation.In one example arrangement, the tag 468(7) within the user/objectregistration header 468 may be the same as the tag 466(8) within theobject registration record 460(N) that points to the user/objectregistration header. Correspondence between these tags 468(7) and 466(8)permits validation that the object registration record and user/objectregistration header match up.

[1363] User/object header 468 also includes an original distributor IDfield 468(3) indicating the original distributor of the correspondingVDE object 300, and the last distributor ID field 468(4) that indicatesthe last distributor within the chain of handling of the object prior toits receipt by electronic appliance 600.

[1364] Header 468 also includes a tag 468(8) allowing validation betweenthe header and the “first” subject record 470(1) which field 468(6)references

[1365] Subject record 470(1) includes a site record number 472(1), auser (or user group) ID field 472(2), a user (or user group) attributesfield 472(3), a field 472(4) referencing user rights table 464, a field472(5) that references to the “next” subject record 470(2) (if there isone), a tag 472(6) used to validate with the header tag 468(8), a tag472(7) used to validate with a corresponding tag in the user rightstable record referenced by field 472(4), a tag 472(9) used to validatewith a tag in the “next” subject record referenced to by field 472(5)and a check value field 472(9).

[1366] User or user group ID 472(2) identifies a user or a user groupauthorized to use the object identified in field 468(5). Thus, thefields 468(5) and 472(2) together form the heart of the access controllist provided by subject table 462. User attributes field 472(3) mayspecify attributes pertaining to use/access to object 300 by the user oruser group specified in fields 472(2) Any number of different users oruser groups may be added to the access control list each with adifferent set of attributes 472(3), by providing additional subjectrecords 470 in the “linked list” structure.

[1367] Subject record reference field 472(4) references one or morerecords within user rights table 464. FIG. 33 shows an example of apreferred format for a user rights table record 464(k). User rightsrecord 464(k) may include a URT header 478, a record rights header 476,and a set of user choice records 478. URT header 474 may include a siterecord number field, a field 474(2) specifying the number of rightsrecords within the URT record 464(k), a field 474(3) referencing a“first” rights record (i.e., to rights record header 476), a tag 474(4)used to validate the lookup from the subject table 462, a tag 474(5)used to validate the lookup to the rights record header 476, and a checkvalue field 474(6).

[1368] Rights record header 476 in the preferred embodiment may includesite record number field 476(1), a right ID field 476(2), a field 476(3)referencing the “next” rights record 476(2), a field 476(4) referencinga first set of user choice records 478(1), a tag 476(5) to allowvalidation with URT header tag 474(5), a tag 476(6) to allow validationwith a user choice record tag 478(6), and a check value field 476(7).Right ID field 476(2) may, for example, specify the type of rightconveyed by the rights record 476(e.g., right to use, right todistribute, right to read, right to audit, etc.)

[1369] The one or more user choice records 478 referenced by rightsrecord header 476 sets forth the user choices corresponding to accessand/or use of the corresponding VDE object 300. There will typically bea rights record 476 for each right authorized to the corresponding useror user group. These rights govern use of the VDE object 300 by thatuser or user group. For instance, the user may have an “access” right,and an “extraction” right, but not a “copy” right. Other rightscontrolled by rights record 476 (which is derived from PERC 808 using aREGISTER method in the preferred embodiment) include distributionrights, audit rights, and pricing rights. When an object 300 isregistered with the electronic appliance 600 and is registered with aparticular user or user group, the user may be permitted to select amongvarious usage methods set forth in PERC 808. For instance, a VDE object300 might have two required meter methodologies: one for billingpurposes, and one for accumulating data concerning the promotionalmaterials used by the user. The user might be given the choice of avariety of meter/billing methods, such as payment by VISA or MasterCard;choosing between billing based upon the quantity of material retrievedfrom an information database, based on the time of use, and or both. Theuser might be offered a discount on time and/or quantity billing if heis willing to allow certain details concerning his retrieval of contentto be provided to third parties (e.g., for demographic purposes). At thetime of registration of an object and/or user for the object, the userwould be asked to select a particular meter methodology as the “activemetering method” for the first acquired meter. A VDE distributor mightnarrow the universe of available choices for the user to a subset of theoriginal selection array stipulated by PERC 808. These user selectionand configuration settings are stored within user choice records 480(1),480(2), 480(N). The user choice records need not be explicitly set forthwithin user rights table 464; instead, it is possible for user choicerecords 480 to refer (e.g., by site reference number) to particular VDEmethods and/or information parameterizing those methods. Such referenceby user choice records 480 to method 1000 should be validated byvalidation tags contained within the user choice records. Thus, userchoice records 480 in the preferred embodiment may select one or moremethods 1000 for use with the corresponding VDE object 300 (as is shownin FIG. 27). These user choice records 480 may themselves fully definethe methods 1000 and other information used to build appropriatecomponents assemblies 690 for implementing the methods. Alternatively,the user/object record 462 used to reference the user rights record 464may also reference the PERC 808 corresponding to VDE object 300 toprovide additional information needed to build the component assembly690 and/or otherwise access the VDE object 300 For example, PERC 808 maybe accessed to obtain MDEs 1202 pertaining to the selected methods,private body and/or rights keys for decrypting and/or encrypting objectcontents, and may also be used to provide a checking capability ensuringthat the user rights record conveys only those rights authorized by acurrent authorization embodied within a PERC.

[1370] In one embodiment provided by the present invention, aconventional database engine may be used to store and organize securedatabase 610, and the encryption layers discussed above may be “on topof” the conventional database structure. However, if such a conventionaldatabase engine is unable to organize the records in secure database 610and support the security considerations outlined above, then electronicappliance 600 may maintain separate indexing structures in encryptedform. These separate indexing structures can be maintained by SPE 503.This embodiment would require SPE 503 to decrypt the index and searchdecrypted index blocks to find appropriate “site record IDs” or otherpointers. SPE 503 might then request the indicated record from theconventional database engine If the record ID cannot be checked againsta record list, SPE 503 might be required to ask for the data file itselfso it can retrieve the desired record. SPE 503 would then performappropriate authentication to ensure that the file has not been tamperedwith and that the proper block is returned. SPE 503 should not simplypass the index to the conventional database engine (unless the databaseengine is itself secure) since this would allow an incorrect record tobe swapped for the requested one.

[1371]FIG. 34 is an example of how the site record numbers describedabove may be used to access the various data structures within securedatabase 610. In this example, secure database 610 further includes asite record table 482 that stores a plurality of site record numbers.Site record table 482 may store what is in effect a “master list” of allrecords within secure database 610. These site record numbers stored bysite record table 482 permit any record within secure database 610 to beaccessed. Thus, some of the site records within site record table 482may index records with an object registration table 460, other siterecord numbers within the site record table may index records within theuser/object table 462, still other site record numbers within the siterecord table may access records within URT 464, and still other siterecord numbers within the site record table may access PERCs 808. Inaddition, each of method cores 1000′ may also include a site recordnumber so they may be accessed by site record table 482.

[1372]FIG. 34A shows an example of a site record 482(j) within siterecord table 482. Site record 482(j) may include a field 484(1)indicating the type of record, a field 484(2) indicating the owner orcreator of the record, a “class” field 484(3) and an “instance” field484(4) providing additional information about the record to which thesite record 482(j) points; a specific descriptor field 484(5) indicatingsome specific descriptor (e.g., object ID) associated with the record;an identification 484(6) of the table or other data structure which thesite record references: a reference and/or offset within that datastructure indicating where the record begins; a validation tag 484(8)for validating the record being looked up, and a check value field484(9). Fields 484(6) and 484(7) together may provide the mechanism bywhich the record referenced to by the site record 484(j) is actuallyphysically located within the secure database 610.

[1373] Updating Secure Database 610

[1374]FIG. 35 show an example of a process 1150 which can be used by aclearinghouse, VDE administrator or other VDE participant to update thesecure database 610 maintained by an end user's electronic appliance 600For example, the process 1500 shown in FIG. 35 might be used to collect“audit trail” records within secure database 610 and/or provide newbudgets and permissions (e.g., PERCs 808 in response to an end user'srequest.

[1375] Typically, the end user's electronic appliance 600 may initiatecommunications with a clearinghouse (Block 1152). This contact may, forexample, be established automatically or in response to a user command.It may be initiated across the electronic highway 108, or across othercommunications networks such as a IN, WAN, two-way cable or usingportable media exchange between electronic appliances. The process ofexchanging administrative information need not occur in a single “online” session, but could instead occur over time based on a number ofdifferent one-way and/or two-way communications over the same ordifferent communications means. However, the process 1150 shown in FIG.35 is a specific example where the end user's electronic appliance 600and the other VDE participant (e.g., a clearinghouse) establish atwo-way real-time interactive communications exchange across a telephoneline, network, electronic highway 108, etc.

[1376] The end user's electronic appliance 600 generally contacts aparticular VDE administrator or clearinghouse. The identity of theparticular clearinghouse is based on the VDE object 300 the user wishesto access or has already accessed. For example, suppose the user hasalready accessed a particular WIDE object 300 and has run out of budgetfor further access. The user could issue a request which will cause herelectronic appliance 600 to automatically contact the ODE administrator,distributor and/or financial clearinghouse that has responsibility forthat particular object. The identity of the appropriate VDE participantsto contact is provided in the example by information within UDEs 1200,MDEs 1202, the Object Registration Table 460 and/or Subject Table 462,for example. Electronic appliance 600 may have to contact multiple VDEparticipants (e.g., to distribute audit records to one participant,obtain additional budgets or other permissions from another participant,etc.). The contact 1152 may in one example be scheduled in accordancewith the FIG. 27 Shipping Table 444 and the FIG. 29 Administrative EventLog 442.

[1377] Once contact is established, the end user's electronic applianceand the clearinghouse typically authenticate one another and agree on asession key to use for the real-time information exchange (Block 1154).Once a secure connection is established, the end user's electronicappliance may determine (e.g., based on Shipping Table 444) whether ithas any administrative object(s), containing audit information that itis supposed to send to the clearinghouse (decision Block 1156). Auditinformation pertaining to several VDE objects 300 may be placed withinthe same administrative object for transmission, or differentadministrative objects may contain audit information about differentobjects. Assuming the end user's electronic appliance has at least onesuch administrative object to send to this particular clearinghouse(“yes” exit to decision Block 1156), the electronic appliance sends thatadministrative object to the clearinghouse via the now-establishedsecure real-time communications (Block 1158). In one specific example, asingle administrative object may be sent an administrative objectcontaining audit information pertaining to multiple VDE objects, withthe audit information for each different object compromising a separate“event” within the administrative object.

[1378] The clearinghouse may receive the administrative object andprocess its contents to determine whether the contents are “valid” and“legitimate.” For example, the clearinghouse may analyze the containedaudit information to determine whether it indicates misuse of theapplicable VDE object 300. The clearinghouse may, as a result of thisanalysis, may generate one or more responsive administrative objectsthat it then sends to the end user's electronic appliance 600 (Block1160). The end user's electronic appliance 600 may process events thatupdate its secure database 610 and or SPU 500 contents based on theadministrative object received (Block 1162). For example, if the auditinformation received by the clearinghouse is legitimate, then theclearinghouse may send an administrative object to the end user'selectronic appliance 600 requesting the electronic appliance to deleteand/or compress the audit information that has been transferred.Alternatively or in addition, the clearinghouse may request additionalinformation from the end-user electronic appliance 600 at this stage(e.g., retransmission of certain information that was corrupted duringthe initial transmission, transmission of additional information notearlier transmitted, etc.). If the clearinghouse detects misuse based onthe received audit information, it may transmit an administrative objectthat revokes or otherwise modifies the end user's right to furtheraccess the associated VDE objects 300.

[1379] The clearinghouse may, in addition or alternatively, send anadministrative object to the end user's electronic appliance 600 thatinstructs the electronic appliance to display one or more messages tothe user These messages may inform the user about certain conditionsand/or they may request additional information from the user Forexample, the message may instruct the end user to contact theclearinghouse directly by telephone or otherwise to resolve an indicatedproblem, enter a PIN, or it may instruct the user to contact a newservice company to re-register, the associated VDE object.Alternatively, the message may tell the end user that she needs toacquire new usage permissions for the object, and may inform the user ofcost, status and other associated information.

[1380] During the same or different communications exchange, the same ordifferent clearinghouse may handle the end user's request for additionalbudget and/or permission pertaining to VDE object 300. For example, theend user's electronic appliance 600 may (e.g., in response to a userinput request to access a particular VDE object 300) send anadministrative object to the clearinghouse requesting budgets and/orother permissions allowing access (Block 1164). As mentioned above, suchrequests may be transmitted in the form of one or more administrativeobjects, such as, for example, a single administrative object havingmultiple “events” associated with multiple requested budgets and/orother permissions for the same or different VDE objects 300. Theclearinghouse may upon receipt of such a request, check the end user'scredit, financial records, business agreements and/or audit histories todetermine whether the requested budgets and/or permissions should begiven. The clearinghouse may, based on this analysis, send one or moreresponsive administrative objects which cause the end user's electronicappliance 600 to update its secure database in response (Block 1166,1168). This updating might, for example, comprise replacing an expiredPERC 808 with a fresh one, modifying a PERC to provide additional (orlesser) rights, etc. Steps 1164-1168 may be repeated multiple times inthe same or different communications session to provide further updatesto the end user's secure database 610.

[1381]FIG. 36 shows an example of how a new record or element may beinserted into secure database 610. The load process 1070 shown in FIG.35 checks each data element or item as it is loaded to ensure that ithas not been tampered with, replaced or substituted. In the process 1070shown in FIG. 35, the first step that is performed is to check to see ifthe current user of electronic appliance 600 is authorized to insert theitem into secure database 610 (block 1072). This test may involve, inthe preferred embodiment, loading (or using already loaded) appropriatemethods 1000 and other data structures such as UDEs 1200 into an SPE503, which then authenticates user authorization to make the change tosecure database 610 (block 1074). If the user is approved as beingauthorized to make the change to secure database 610, then SPE 503 maycheck the integrity of the element to be added to the secure database bydecrypting it (block 1076) and determining whether it has become damagedor corrupted (block 1078). The element is checked to ensure that itdecrypts properly using a predetermined management file key, and thecheck value may be validated. In addition, the public and private headerID tags (if present) may be compared to ensure that the proper elementhas been provided and had not been substituted, and the unique elementtag ID compared against the predetermined element tag. If any of thesetests fail, the element may be automatically rejected, error corrected,etc. Assuming the element is found to have integrity, SPE 503 mayre-encrypt the information (block 1080) using a new key for example (seeFIG. 37 discussion below). In the same process step an appropriate tagis preferably provided so that the information becomes encrypted withina security wrapper having appropriate tags contained therein (block1082). SPE 503 may retain appropriate tag information so that it canlater validate or otherwise authenticate the item when it is again readfrom secure database 610 (block 1084). The now-secure element within itssecurity wrapper may then be stored within secure database 610.

[1382]FIG. 37 shows an example of a process 1050 used in the preferredembodiment database to securely access an item stored in secure database610 In the preferred embodiment, SPE 503 fist accesses and reads in theitem from secure database 610 records. SPE 503 reads this informationfrom secure database 610 in encrypted form, and may “unwrap” it (block1052) by decrypting it (block 1053) based on access keys internallystored within the protected memory of an SPU 500. In the preferredembodiment, this “unwrap” process 1052 involves sending blocks ofinformation to encrypt/decrypt engine 522 along with a management filekey and other necessary information needed to decrypt. Decrypt engine522 may return “plaintext” information that SPE 503 then checks toensure that the security of the object has not been breached and thatthe object is the proper object to be used (block 1054). SPE 503 maythen check all correlation and access tags to ensure that the read-inelement has not been substituted and to guard against other securitythreats (block 1054). Part of this “checking” process involves checkingthe tags obtained from the secure database 610 with tags containedwithin the secure memory or an SPU 500 (block 1056). These tags storedwithin SPU 500 may be accessed from SPU protected memory (block 1056)and used to check further the now-unwrapped object. Assuring thischecking process 1054 does not reveal any improprieties (and block 1052also indicates that the object has not become corrupted or otherwisedamaged), SPE 503 may then access or otherwise use the item (block1058). Once use of the item is completed, SPE 503 may need to store theitem back into secure database 610 if it has changed. If the item haschanged, SPE 503 will send the item in its changed form toencrypt/decrypt engine 522 for encryption (block 1060), providing theappropriate necessary information to the encrypt/decrypt engine (e.g.,the appropriate same or different management file key and data) so thatthe object is appropriately encrypted. A unique, new tag and/orencryption key may be used at this stage to uniquely tag and/or encryptthe item security wrapper (block 1062; see also detailed FIG. 37discussion below). SPE 503 may retain a copy of the key and/or tagwithin a protected memory of SPU 500 (block 1064) so that the SPE candecrypt and validate the object when it is again read from securedatabase 610.

[1383] The keys to decrypt secure database 610 records are, in thepreferred embodiment, maintained solely within the protected memory ofan SPU 500. Each index or record update that leaves the SPU 500 may betime stamped, and then encrypted with a unique key that is determined bythe SPE 503. For example, a key identification number may be placed “inplain view” at the front of the records of secure database 610 so theSPE 503 can determine which key to use the next time the record isretrieved. SPE 503 can maintain the sate ID of the record or index, thekey identification number associated with it, and the actual keys in thelist internal to the SPE. At some point, this internal list may fill up.At this point, SPE 503 may call a maintenance routine that re-encryptsitems within secure database 610 containing changed information. Some orall of the items within the data structure containing changedinformation may be read in, decrypted, and then re-encrypted with thesame key. These items may then be issued the same key identificationnumber. The items may then be written out of SPE 503 back into securedatabase 610. SPE 503 may then clear the internal list of item IDs andcorresponding key identification numbers. It may then begin again theprocess of assigning a different key and a new key identification numberto each new or changed item. By using this process, SPE 503 can protectthe data structures (including the indexes) of secure database 610against substitution of old items and against substitution of indexesfor current items. This process also allows SPE 503 to validateretrieved item IDs against the encrypted list of expected IDs.

[1384]FIG. 38 is a flowchart showing this process in more detail.Whenever a secure database 610 item is updated or modified, a newencryption key can be generated for the updated item. Encryption using anew key is performed to add security and to prevent misuse of backupcopies of secure database 610 records The new encryption key for eachupdated secure database 610 record may be stored in SPU 500 securememory with an indication of the secure database record or record(s) towhich it applies.

[1385] SPE 503 may generate a new encryption/decryption key for each newitem it is going to store within secure database 610 (block 1086). SPE503 may use this new key to encrypt the record prior to storing it inthe secure database (block 1088). SPE 503 make sure that it retains thekey so that it can later read and decrypt the record. Such decryptionkeys are, in the preferred embodiment, maintained within protectednon-volatile memory (e.g., NVRAM 534 b) within SPU 500. Since thisprotected memory has a limited size, there may not be enough room withinthe protected memory to store a new key. This condition is tested for bydecision block 1090 in the preferred embodiment. If there is not enoughroom in memory for the new key (or some other event such as the numberof keys stored in the memory exceeding a predetermined number, a timerhas expired, etc.), then the preferred embodiment handles the situationby re-encrypting other records with secure database 610 with the samenew key in order to reduce the number of or change)encryption/decryption keys in use. Thus, one or more secure database 610items may be read from the secure database (block 1092), and decryptedusing the old key(s) used to encrypt them the last time they werestored. In the preferred embodiment, one or more “old keys” areselected, and all secure database items encrypted using the old key(s)are read and decrypted. These records may now be re-encrypted using thenew key that was generated at block 1086 for the new record (block1094). The old key(s) used to decrypt the other record(s) may now beremoved from the SPU protected memory (block 1096), and the new keystored in its place (block 1097). The old key(s) cannot be removed fromsecure memory by block 1096 unless SPE 503 is assured that all recordswithin the secure database 610 that were encrypted using the old key(s)have been read by block 1092 and re-encrypted by block 1904 using thenew key. All records encrypted (or re-encrypted) using the new key maynow be stored in secure database 610 (block 1098). If decision block1090 determines there is room within the SPU 500 protected memory tostore the new key, then the operations of blocks 1092, 1094, 1096 arenot needed and SPE 503 may instead simply store the new key within theprotected memory (block 1097) and store the new encrypted records intosecure database 610 (block 1098).

[1386] The security of secure database 610 files may be further improvedby segmenting the records into “compartments” Differentencryption/decryption keys may be used to protect different“compartments.” This strategy can be used to limit the amount ofinformation within secure database 610 that is encrypted with a singlekey. Another technique for increasing security of secure database 610may be to encrypt different portions of the same records with differentkeys so that more than one key may be needed to decrypt those records.

[1387] Backup of Secure Database 610

[1388] Secure database 610 in the preferred embodiment is backed up atperiodic or other time intervals to protect the information the securedatabase contains. This secure database information may be ofsubstantial value to many VDE participants. Back ups of secure database610 should occur without significant inconvenience to the user, andshould not breach any security.

[1389] The need to back up secure database 610 may be checked at poweron of electronic appliance 600, when SPE 503 is initially invoked, atperiodic time intervals, and if “audit roll up” value or other summaryservices information maintained by SPE 503 exceeds a user set or otherthreshold, or triggered by criteria established by one or more contentpublishers and/or distributors and/or clearinghouse service providersand/or users. The user may be prompted to backup if she has failed to doso by or at some certain point in time or after a certain duration oftime or quantity of usage, or the backup may proceed automaticallywithout user intervention.

[1390] Referring to FIG. 8, backup storage 668 and storage media 670(e.g., magnetic tape) may be used to store backed up information. Ofcourse, any non-volatile media (e.g., one or more floppy diskettes, awritable optical diskette, a hard drive, or the like) may be used forbackup storage 668.

[1391] There are at least two scenarios to backing up secure database610. The first scenario is “site specific,” and uses the security of SPU500 to support restoration of the backed up information. This firstmethod is used in case of damage to secure database 610 due for exampleto failure of secondary storage device 652, inadvertent user damage tothe files, or other occurrences that may damage or corrupt some or allof secure database 610. This first, site specific scenario of back upassumes that an SPU 500 still functions properly and is available torestore backed up information.

[1392] The second back up scenario assumes that the user's SPU 500 is nolonger operational and needs to be, or has been, replaced. This secondapproach peats an authorized VDE administrator or other authorized VDEparticipant to access the stored back up information m order to preventloss of critical data and/or assist the user m recovering from theerror.

[1393] Both of these scenarios are provided by the example of programcontrol steps performed by ROS 602 shown in FIG. 39. FIG. 39 shows anexample back up routine 1250 performed by an electronic appliance 600 toback up secure database 610 (and other information) onto back up storage668. Once a back up has been initiated, as discussed above, back uproutine 1250 generates one or more back up keys (block 1252). Back uproutine 1250 then reads all secure database items, decrypts each itemusing the original key used to encrypt them before they were stored insecure database 610 (block 1254). Since SPU 500 is typically the onlyplace where the keys for decrypting this information within an instanceof secure database 610 are stored, and since one of the scenariosprovided by back up routine 1250 is that SPU 500 completely failed or isdestroyed, back up routine 1250 performs this reading and decryptingstep 1254 so that recovery from a backup is not dependent on knowledgeof these keys within the SPU. Instead, back up routine 1250 encryptseach secure database 610 item with a newly generated back up key(s)(block 1256) and writes the encrypted item to back up store 668 (block1258). This process continues until all items within secure database 610have been read, decrypted, encrypted with a newly generated back upkey(s), and written to the back up store (as tested for by decisionblock 1260).

[1394] The preferred embodiment also reads the summary services auditinformation stored within the protected memory of SPU 500 by SPE summaryservices manager 560, encrypts this information with the newly generatedback up key(s), and writes this summary services information to back upstore 668 (block 1262).

[1395] Finally, back up routine 1250 saves the back up key(s) generatedby block 1252 and used to encrypt in blocks 1256, 1262 onto back upstore 668. It does this in two secure ways in order to cover both of therestoration scenarios discussed above. Back up routine 1250 may encryptthe back up key(s) (along with other information such as the time ofback up and other appropriate information to identify the back up) witha further key or keys such that only SPU 500 can decrypt (block 1264This encrypted information is then written to back up store 668 (block1264). For example, this step may include multiple encryptions using oneor more public keys with corresponding private keys known only to SPU500. Alternatively, a second back up key generated by the SPU 500 andkept only in the SPU may be used for the final encryption in place of apublic key. Block 1264 preferably includes multiple encryption in orderto make it more difficult to attack the security of the back up by“cracking” the encryption used to protect the back up keys. Althoughblock 1262 includes encrypted summary services information on the backup, it preferably does not include SPU device private keys, shared keys,SPU code and other internal security information to prevent thisinformation from ever becoming available to users even in encryptedform.

[1396] The information stored by block 1264 is sufficient to allow thesame SPU 500 that performed (or at least in part performed) back uproutine 1250 to recover the backed up information. However, thisinformation is useless to any device other than that same SPU becauseonly that SPU knows the particular keys used to protect the back upkeys. To cover the other possible scenario wherein the SPU 500 fails ina non-recoverable way, back up routine 1250 provides an additional step(block 1266), of saving the back up key(s) under protection of one ormore further set of keys that may be read by an authorized VDEadministrator. For example, block 1266 may encrypt the back up keys withan “download authorization key” received during initialization of SPU500 from a VDE administrator. This encrypted version of back up keys isalso written to back up store 668 (block 1266). It can be used tosupport restoration of the back up files in the event of an SPU 500failure. More specifically, a VDE administrator that knows the downloadauthorization (or other) keys(s) used by block 1266 may be able torecover the back up key(s) in the back up store 668 and proceed torestore the backed up secure database 610 to the same or differentelectronic appliance 600.

[1397] In the preferred embodiment, the information saved by routine1250 in back up files can be restored only after receiving a back upauthorization from an authorized VDE administrator In most cases, therestoration process will simply be a restoration of secure database 610with some adjustments to account for any usage since the back upoccurred. This may require the user to contact additional providers totransmit audit and billing data and receive new budgets to reflectactivity since the last back up Current summary services informationmaintained within SPU 500 may be compared to the summary servicesinformation stored on the back up to determine or estimate most recentusage activity.

[1398] In case of an SPU 500 failure, an authorized VDE administratormust be contacted to both initialize the replacement SPU 500 and todecrypt the back up files. These processes allow for both SPU failuresand upgrades to new SPUs. In the case of restoration, the back up filesare used to restore the necessary information to the user's system. Inthe case of upgrades, the back up files may be used to validate theupgrade process.

[1399] The back up files may in some instances be used to transfermanagement information between electronic appliances 600. However, thepreferred embodiment may restrict some or all information from beingtransportable between electronic appliances with appropriateauthorizations. Some or all of the back up files may be packaged withinan administrative object and transmitted for analysis, transportation,or other uses.

[1400] As a more detailed example of a need for restoration from back upfiles, suppose an electronic appliance 600 suffers a hard disk failureor other accident that wipes out or corrupts part or all of the securedatabase 610, but assume that the SPU 500 is still functional. SPU 500may include all of the information (e.g. secret keys and the like) itneeds to restore the secure database 610. However, ROS 602 may preventsecure database restoration until a restoration authorization isreceived from a VDE administrator. A restoration authorization maycomprise, for example, a “secret value” that must match a value expectedby SPE 503. A VDE administrator may, if desired, only provide thisrestoration authorization after, for example, summary servicesinformation stored within SPU 500 is transmitted to the administrator inan administrative object for analysis. In some circumstances, a VDEadministrator may require that a copy (partial or complete) of the backup files be transmitted to it within an administrative object to checkfor indications of fraudulent activities by the user. The restorationprocess, once authorized, may require adjustment of restored budgetrecords and the like to reflect activity since the last back up, asmentioned above.

[1401]FIG. 40 is an example of program controlled “restore” routine 1268performed by electronic appliance 600 to restore secure database 610based on the back up provided by the routine shown in FIG. 38. Thisrestore may be used, for example, in the event that an electronicappliance 600 has failed but can be recovered or “reinitialized” throughcontact with a VDE administrator for example. Since the preferredembodiment does not permit an SPU 500 to restore from backup unless anduntil authorized by a VDE administrator, restore routine 1268 begins byestablishing a secure communication with a VDE administrator that canauthorize the restore to occur (block 1270). Once SPU 500 and the VDEadministrator authenticate one another (part of block 1270), the VDEadministrator may extract “work in progress” and summary values from theSPU 500's internal non-volatile memory (block 1272. The VDEadministrator may use this extracted information to help determine, forexample, whether there has been a security violation, and also permits afailed SPU 500 to effectively “dump” its contents to the VDEadministrator to permit the VDE administrator to handle the contents.The SPU 500 may encrypt this information and provide it to the VDEadministrator packaged in one or more administrative objects. The VDEadministrator may then request a copy of some or all of the currentbackup of secure database 610 from the SPU 500 (block 1274). Thisinformation may be packaged by SPU 500 into one or more administrativeobjects, for example, and sent to the VDE administrator. Upon receivingthe information, the VDE administrator may read the summary servicesaudit information from the backup volume (i.e., information stored byFIG. 38 block 1262) to determine the summary values and otherinformation stored at time of backup. The VDE administrator may alsodetermine the time and date the backup was made by reading theinformation stored by FIG. 38 block 1264.

[1402] The VDE administrator may at this point restore the summaryvalues and other information within SPU 500 based on the informationobtained by block 1272 and from the backup (block 1276). For example,the VDE administrator may reset SPU internal summary values and countersso that they are consistent with the last backup. These values may beadjusted by the VDE administrator based on the “work in progress”recovered by block 1272, the amount of time that has passed since thebackup, etc. The goal may typically be to attempt to provide internalSPU values that are equal to what they would have been had the failurenot occurred.

[1403] The VDE administrator may then authorize SPU 500 to recover itssecure database 610 from the backup files (block 1278). This restorationprocess replaces all secure database 610 records with the records fromthe backup. The VDE administrator may adjust these records as needed bypassing commands to SPU 500 during or after the restoration process.

[1404] The VDE administrator may then compute bills based on therecovered values (block 1280), and perform other actions to recover fromSPU downtime (block 1282). Typically, the goal is to bill the user andadjust other VDE 100 values pertaining to the failed electronicappliance 600 for usage that occurred subsequent to the last backup butprior to the failure. This process may involve the VDE administratorobtaining, from other VDE participants, reports and other informationpertaining to usage by the electronic appliance prior to its failure andcomparing it to the secure database backup to determine which usage andother events are not yet accounted for.

[1405] In one alternate embodiment, SPU 500 may have sufficientinternal, non-volatile memory to allow it to store some or all of securedatabase 610. In this embodiment, the additional memory may be providedby additional one or more integrated circuits that can be containedwithin a secure enclosure, such as a tamper resistant metal container orsome form of a chip pack containing multiple integrated circuitcomponents, and which impedes and/or evidences tampering attempts,and/or disables a portion or all of SPU 500 or associated critical keyand/or other control information in the event of tampering. The sameback up routine 1250 shown in FIG. 38 may be used to back up this typeof information, the only difference being that block 1254 may read thesecure database item from the SPU internal memory and may not need todecrypt it before encrypting it with the back up key(s).

[1406] Event-Driven VDE Processes

[1407] As discussed above, processes provided by/under the preferredembodiment rights operating system (ROS) 602 may be “event driven.” This“event driven” capability facilitates integration and extendibility.

[1408] An “event” is a happening at a point in time. Some examples of“events” are a user striking a key of a keyboard, arrival of a messageor an object 300, expiration of a timer, or a request from anotherprocess.

[1409] In the preferred embodiment, ROS 602 responds to an “event” byperforming a process in response to the event. ROS 602 dynamicallycreates active processes and tasks in response to the occurrence of anevent. For example, ROS 602 may create and begin executing one or morecomponent assemblies 690 for performing a process or processes inresponse to occurrence of an event. The active processes and tasks mayterminate once ROS 602 has responded to the event. This ability todynamically create (and end) tasks in response to events provides greatflexibility, and also permits limited execution resources such as thoseprovided by an SPU 500 to perform a virtually unlimited variety ofdifferent processes in different contexts.

[1410] Since an “event” may be any re of happening, there are anunlimited number of different events. Thus, any attempt to categorizeevents into different types will necessarily be a generalization.Keeping this in mind, it is possible to categorize eventsprovided/supported by the preferred embodiment into two broadcategories:

[1411] user-initiated events; and

[1412] system-initiated events.

[1413] Generally, “user-initiated” events are happenings attributable toa user (or a user application). A common “user-initiated” event is auser's request (e.g., by pushing a keyboard button, or transparentlyusing redirector 684) to access an object 300 or other VDE-protectedinformation.

[1414] “System-initiated” events are generally happenings notattributable to a user. Examples of system initiated events include theexpiration of a timer indicating that information should be backed tonon-volatile memory, receipt of a message from another electronicappliance 600, and a service call generated by another process (whichmay have been started to respond to a system-initiated event and/or auser-initiated event).

[1415] ROS 602 provided by the preferred embodiment responds to an eventby specifying and beginning processes to process the event. Theseprocesses are, in the preferred embodiment, based on methods 1000. Sincethere are an unlimited number of different types of events, thepreferred embodiment supports an unlimited number of different processesto process events. This flexibility is supported by the dynamic creationof component assemblies 690 from independently deliverable modules suchas method cores 1000′, load modules 1100, and data structures such asUDEs 1200. Even though any categorization of the unlimited potentialtypes of processes supported/provided by the preferred embodiment willbe a generalization, it is possible to generally classify processes asfalling within two categories:

[1416] processes relating to use of VDE protected information; and

[1417] processes relating to VDE administration.

[1418] “Use” and “Administrative” Processes

[1419] “Use” processes relate in some way to use of VDE-protectedinformation. Methods 1000 provided by the preferred embodiment mayprovide processes for creating and maintaining a chain of control foruse of VDE-protected information. One specific example of a “use” typeprocess is processing to permit a user to open a VDE object 300 andaccess its contents. A method 1000 may provide detailed use-relatedprocesses such as, for example, releasing content to the user asrequested (if permitted), and updating meters, budgets, audit trails,etc. Use-related processes are often user-initiated, but some useprocesses may be system-initiated. Events that trigger a VDE use-relatedprocess may be called “use events.”

[1420] An “administrative” process helps to keep VDE 100 working. Itprovides processing that helps support the transaction management“infrastructure” that keeps VDE 100 running securely and efficiently.Administrative processes may, for example, provide processing relatingto some aspect of creating, modifying and/or destroying VDE-protecteddata structures that establish and maintain VDE's chain of handling andcontrol. For example, “administrative” processes may store, update,modify or destroy information contained within a VDE electronicappliance 600 secure database 610. Administrative processes also mayprovide communications services that establish, maintain and supportsecure communications between different VDE electronic appliances 600.Events that trigger administrative processes may be called“administrative events.”

[1421] Reciprocal Methods

[1422] Some VDE processes are paired based on the way they interacttogether One VDE process may “request” processing services from anotherVDE process. The process that requests processing services may be calleda “request process.” The “request” constitutes an “event” because ittriggers processing by the other VDE process in the pair. The VDEprocess that responds to the “request event” may be called a “responseprocess.” The “request process” and “response process” may be called“reciprocal processes.”

[1423] The “request event” may comprise, for example, a message issuedby one VDE node electronic appliance 600 or process for certaininformation. A corresponding “response process” may respond to the“request event” by, for example, sending the information requested inthe message. This response may itself constitute a “request event” if ittriggers a further VDE “response process.” For example, receipt of amessage in response to an earlier-generated request may trigger a “replyprocess.” This “reply process” is a special type of “response process”that is triggered in response to a “reply” from another “responseprocess.” There may be any number of “request” and “response” processpairs within a given VDE transaction.

[1424] A “request process” and its paired “response process” may beperformed on the same VDE electronic appliance 600, or the two processesmay be performed on different VDE electronic appliances. Communicationbetween the two processes in the pair may be by way of a secure(VDE-protected) communication, an “out of channel” communication, or acombination of the two.

[1425]FIGS. 41a-41 d are a set of examples that show how the chain ofhandling and control is enabled using “reciprocal methods.” A chain ofhandling and control is constructed, in part, using one or more pairs of“reciprocal events” that cooperate in request-response manner. Pairs ofreciprocal events may be managed in the preferred embodiment in one ormore “reciprocal methods.” As mentioned above, a “reciprocal method” isa method 1000 that can respond to one or more “reciprocal events.”Reciprocal methods contain the two halves of a cooperative process thatmay be securely executed at physically and/or temporally distant VDEnodes. The reciprocal processes may have a flexibly defined informationpassing protocols and information content structure. The reciprocalmethods may, in fact, be based on the same or different method core1000′ operating in the same or different VDE nodes 600. VDE nodes 600Aand 600B shown in FIG. 41a may be the same physical electronic appliance600 or may be separate electronic appliances.

[1426]FIG. 41a is an example of the operation of a single pair ofreciprocal events. In VDE node 600A, method 1000 a is processing anevent that has a request that needs to be processed at VDE node 600B.The method 1000 a (e.g., based on a component assembly 690 including itsassociated load modules 1100 and data) that responds to this “request”event is shown in FIG. 41a as 1450. The process 1450 creates a request(1452) and, optionally, some information or data that will be sent tothe other VDE node 1000 b for processing by a process associated withthe reciprocal event. The request and other information may betransmitted by any of the transport mechanisms described elsewhere inthis disclosure.

[1427] Receipt of the request by VDE node 600 b comprises a responseevent at that node. Upon receipt of the request, the VDE node 600 b mayperform a “reciprocal” process 1454 defined by the same or differentmethod 1000b to respond to the response event. The reciprocal process1454 may be based on a component assembly 690 (e.g., one or more loadmodules 1100, data, and optionally other methods present in the VDE node600B).

[1428]FIG. 41b extends the concepts presented in FIG. 4a to include aresponse from VDE node 600B back to VDE node 600A. The process starts asdescribed for FIG. 41a through the receipt and processing of the requestevent and information 1452 by the response process 1454 in VDE node600B. The response process 1454 may, as part of its processing,cooperate with another request process (1468) to send a response 1469back to the initiating VDE node 600A. A corresponding reciprocal process1470 provided by method 1000A may respond to and process this requestevent 1469. In this manner, two or more VDE nodes 600A, 600B maycooperate and pass configurable information and requests between methods1000A, 1000B executing in the nodes. The first and secondrequest-response sequences [(1450, 1452, 1454) and (1468, 1469, 1470)]may be separated by temporal and spatial distances. For efficiency, therequest (1468) and response (1454) processes may be based on the samemethod 1000 or they may be implemented as two methods in the same ordifferent method core 1000′. A method 1000 may be parameterized by an“event code” so it may provide different behaviors/results for differentevents, or different methods may be provided for different events.

[1429]FIG. 41c shows the extension the control mechanism described inFIGS. 41a-41 b to three nodes (600A, 600B, 600C). Each request-responsepair operates in the manner as described for FIG. 41b, with severalpairs linked together to form a chain of control and handling betweenseveral VDE nodes 600A, 600B, 600C. This mechanism may be used to extendthe chain of handling and control to an arbitrary number of VDE nodesusing any configuration of nodes. For example, VDE node 600C mightcommunicate directly to VDE node 600A and communicate directly to VDE600B, which in turn communicates with VDE node 600A. Alternately, VDEnode 600C might communicate directly with VDE node 600A, VDE node 600Amay communicate with VDE node 600B, and VDE node 600B may communicatewith VDE node 600C.

[1430] A method 1000 may be parameterized with sets of events thatspecify related or cooperative functions. Events may be logicallygrouped by function (e.g., use, distribute), or a set of reciprocalevents that specify processes that may operate in conjunction with eachother. FIG. 41d illustrates a set of “reciprocal events” that supportcooperative processing between several VDE nodes 102, 106, 112 in acontent distribution model to support the distribution of budget. Thechain of handling and control, in this example, is enabled by using aset of “reciprocal events” specified within a BUDGET method. FIG. 41d isan example of how the reciprocal event behavior within an example BUDGETmethod (1510) work in cooperation to establish a chain of handling andcontrol between several VDE nodes The example BUDGET method 1510responds to a “use” event 1478 by performing a “use” process 1476 thatdefines the mechanism by which processes are budgeted. The BUDGET method1510 might, for example, speck, a use process 1476 that compares a metercount to a budget value and fail the operation if the meter countexceeds the budget value. It might also write an audit trail thatdescribes the results of said BUDGET decisions. Budget method 1510 mayrespond to a “distribute” event by performing a distribute process 1472that defines the process and/or control information for furtherdistribution of the budget. It may respond to a “request” event 1480 byperforming a request process 1480 that specifies how the user mightrequest use and/or distribution rights from a distributor. It mayrespond to a “response” event 1482 by performing a response process 1484that specifies the manner in which a distributor would respond torequests from other users to whom they have distributed some (or all) oftheir budget to. It may respond to a “reply” event 1474 by performing areply process 1475 that might specify how the user should respond tomessage regranting or denying (more) budget.

[1431] Control of event processing, reciprocal events, and theirassociated methods and method components is provided by PERCs 808 in thepreferred embodiment. These PERCs (808) might reference administrativemethods that govern the creation, modification, and distribution of thedata structures and administrative methods that permit access,modification, and further distribution of these items. In this way, eachlink in the chain of handling and control might, for example, be able tocustomize audit information, alter the budget requirements for using thecontent, and/or control further distribution of these rights in a mannerspecified by prior members along the distribution chain.

[1432] In the example shown in FIG. 41d, a distributor at a VDEdistributor node (106) might request budget from a content creator atanother node (102). This request may be made in the context of a secureVDE communication or it may be passed in an “out-of-channel”communication (e.g. a telephone call or letter). The creator 102 maydecide to grant budget to the distributor 106 and processes a distributeevent (1452 in BUDGET method 1510 at VDE node 102). A result ofprocessing the distribute event within the BUDGET method might be asecure communication (1454) between VDE nodes 102 and 106 by which abudget granting use and redistribute rights to the distributor 106 maybe transferred from the creator 102 to the distributor. Thedistributor's VDE node 106 may respond to the receipt of the budgetinformation by processing the communication using the reply process1475B of the BUDGET method 1510. The reply event processing 1475B might,for example, install a budget and PERC 808 within the distributor's VDE106 node to permit the distributor to access content or processes forwhich access is control at least in part by the budget and/or PERC. Atsome point, the distributor 106 may also desire to use the content towhich she has been granted rights to access.

[1433] After registering to use the content object, the user 112 wouldbe required to utilize an array of “use” processes 1476C to, forexample, open, read, write, and/or close the content object as part ofthe use process.

[1434] Once the distributor 106 has used some or all of her budget, shemay desire to obtain additional budget. The distributor 106 might theninitiate a process using the BUDGET method request process (1480B).Request process 1480B might initiate a communication (1482AB) with thecontent creator VDE node 102 requesting more budget and perhapsproviding details of the use activity to date (e.g., audit trails). Thecontent creator 102 processes the ‘get more budget’ request event 1482ABusing the response process (1484A the creator's BUDGET method 1510A.Response process 1484A might, for example, make a determination if theuse information indicates proper use of the content, and/or if thedistributor is credit worthy for more budget. The BUDGET method responseprocess 1484A might also initiate a financial transaction to transferfunds from the distributor to pay for said use, or use the distributeprocess 1472A to distribute budget to the distributor 106. A response tothe distributor 106 granting more budget (or denying more budget) mightbe sent immediately as a response to the request communication 1482AB,or it might be sent at a later time as part of a separate communication.The response communication, upon being received at the distributor's VDEnode 106, might be processed using the reply process 1475B within thedistributor's copy of the BUDGET method 1510B. The reply process 1475Bmight then process the additional budget in the same manner as describedabove.

[1435] The chain of handling and control may, in addition to postingbudget information, also pass control information that governs themanner in which said budget may be utilized. For example, the controlinformation specified in the above example may also contain controlinformation describing the process and limits that apply to thedistributor's redistribution of the right to use the creator's contentobject. Thus, when the distributor responds to a budget request from auser a communication between a user at VDE node 112 to the distributorat VDE node 106 similar in nature to the one described above between VDEnodes 106 and 102) using the distribute process 1472B within thedistributor's copy of the BUDGET method 1510B, a distribution andrequest/response/reply process similar to the one described above mightbe initiated.

[1436] Thus, in this example a single method can provide multipledynamic behaviors based on different “triggering” events. For example,single BUDGET method 1510 might support any or all of the events listedbelow: Event type Event Process Description ”Use“ use budget Use budget.Events request more budget Request more money for Request budget. Eventsrequest audit by auditor Request that auditor #1 audit Processed by #1the budget use. User Node request budget deletion Request that budget beRequest deleted from system. Process request method updated Updatemethod used for 1480c auditing. request to change auditors Change fromauditor 1 to auditor 2. or vice versa. request different audit Changetime interval berween interval audits. request ability to provideRequest ability to provide budget copies copies of a budget. requestability to Request ability to distribute a distribute budget budget toother users request account status Request information on current statusof an account Request New Method Request new method Request MethodUpdate Request update of method Request Method Deletion Request deletionof method Response receive more budget Allocate more money to Eventsbudget. Processed by receive method update Update method. User Nodereceive auditor change Change from one auditor to Request anotherProcess receive change to audit Change interval between 1480C intervalaudits. receive budget deletion Delete budget. provide audit to auditor#1 Forward audit information to auditor #1. provide audit to auditor #2Forward audit information to auditor #2 receive account status Provideaccount status. Receive New Receive new budget. Receive Method UpdateReceive updated information Receive More Receive more for budget. SentAudit Send audit information. Perform Deletion Delete information”Distribute“ Create New Create new budget. Events Provide More Providemore for budget. Audit Perform audit. Delete Delete informationReconcile Reconcile budget and auditing Copy Copy budget. DistributeDistribute budget. Method Modification Modify method Display MethodDisplay requested method ”Request“ Delete Delete information Events GetNew Get new budget Processed by Get More Get more for budget DistributorGet Updated Get updated information Node Get Audited Get auditinformation Request Process 1484B ”Response Provide New to user Providenew budget to user Events“ Provide More to user Provide more budget touser Processed by Provide Update to user Provided updated budget toDistributor user Node Audit user Audit a specified user Request Deleteuser's method Delete method belonging to Process user 1484B

[1437] Examples of Reciprocal Method Processes

[1438] A. BUDGET

[1439]FIGS. 42a, 42 b, 42 c and 42 d, respectively, are flowcharts ofexample process control steps performed by a representative example ofBUDGET method 2250 provided by the preferred embodiment. In thepreferred embodiment, BUDGET method 2250 may operate in any of fourdifferent modes:

[1440] use (see FIG. 42a)

[1441] administrative request (see FIG. 42b)

[1442] administrative response (see FIG. 42c)

[1443] administrative reply (see FIG. 42d).

[1444] In general, the “use” mode of BUDGET method 2250 is invoked inresponse to an event relating to the use of an object or its content.The “administrative request” mode of BUDGET method 2250 is invoked by oron behalf of the user in response to some user action that requirescontact with a VDE financial provider, and basically its task is to sendan administrative request to the VDE financial provider. The“administrative response” mode of BUDGET method 2250 is performed at theVDE financial provider in response to receipt of an administrativerequest sent from a VDE node to the VDE financial provider by the“administrative request” invocation of BUDGET method 2250 shown in FIG.42b. The “administrative response” invocation of BUDGET method 2250results in the transmission of an administrative object from VDEfinancial provider to the VDE user node. Finally, the “administrativereply” invocation of BUDGET method 2250 shown in FIG. 42d is performedat the user VDE node upon receipt of the administrative object sent bythe “administrative response” invocation of the method shown in FIG.42c.

[1445] In the preferred embodiment, the same BUDGET method 2250 performseach of the four different step sequences shown in FIGS. 42a-42 d. Inthe preferred embodiment, different event codes may be passed to theBUDGET method 2250 to invoke these various different modes. Of course,it would be possible to use four separate BUDGET methods instead of asingle BUDGET method with four different “dynamic personalities,” butthe preferred embodiment obtains certain advantages by using the sameBUDGET method for each of these four types of invocations.

[1446] Looking at FIG. 42a, the “use” invocation of BUDGET method 2250first primes the Budget Audit Trail (blocks 2252, 2254). It then obtainsthe DTD for the Budget UDE, which it uses to obtain and read the BudgetUDE blocks 2256-2262). BUDGET method 2250 in this “use” invocation maythen determine whether a Budget Audit date has expired, and terminate ifit has (“yes” exit to decision block 2264; blocks 2266, 2268). So longas the Budget Audit date has not expired, the method may then update theBudget using the atomic element and event counts (and possibly otherinformation) (blocks 2270, 2272), and may then save a Budget User Auditrecord in a Budget Audit Trail UDE (blocks 2274, 2276) beforeterminating (at terminate point 2278).

[1447] Looking at FIG. 42b, the first six steps (blocks 2280-2290) maybe performed by the user VDE node in response to some user action (e.g.,request to access new information, request for a new budget, etc.). This“administrative request” invocation of BUDGET method 2250 may prime anaudit trail (blocks 2280, 2282). The method may then place a request foradministrative processing of an appropriate Budget onto a request queue(blocks 2284, 2286). Finally, the method may save appropriate audittrail information (blocks 2288, 2290). Sometime later, the user VDE nodemay prime a communications audit trail (blocks 2292. 2294), and may thenwrite a Budget Administrative Request into an administrative object(block 2296). This step may obtain information from the secure databaseas needed from such sources such as, for example, Budget UDE; BudgetAudit Trail UDE(s); and Budget Administrative Request Record(s) (block2298).

[1448] Block 2296 may then communicate the administrative object to aVDE financial provider, or alternatively, block 2296 may passadministrative object to a separate communications process or methodthat arranges for such communications to occur. If desired, method 2250may then save a communications audit trail (blocks 2300, 2302) beforeterminating (at termination point 2304).

[1449]FIG. 42c is a flowchart of an example of process control stepsperformed by the example of BUDGET method 2250 provided by the preferredembodiment operating in an “administrative response” mode. Steps shownin FIG. 42c would, for example, be performed by a VDE financial providerwho has received an administrative object contacting a Budgetadministrative request as created (and communicated to a VDEadministrator for example) by FIG. 42b (block 2296).

[1450] Upon receiving the administrative object, BUDGET method 2250 atthe VDE financial provider site may prime a budget communications andresponse audit trail (blocks 2306, 2308), and may then unpack theadministrative object and retrieve the budget request(s), audit trail(s)and record(s) it contains (block 2310). This information retrieved fromthe administrative object may be written by the VDE financial providerinto its secure database (block 2312). The VDE financial provider maythen retrieve the budget request(s) and determine the response method itneeds to execute to process the request (blocks 2314, 2316). BUDGETmethod 2250 may send the event(s) contained in the request record(s) tothe appropriate response method and may generate response records andresponse requests based on the RESPONSE method (block 2318). The processperformed by block 2318 may satisfy the budget request by writingappropriate new response records into the VDE financial provider'ssecure database (block 2320). BUDGET method 2250 may then write theseBudget administrative response records into an administrative object(blocks 2322, 2324), which it may then communicate back to the user nodethat initiated the budget request. BUDGET method 2250 may then savecommunications and response processing audit trail information intoappropriate audit trail UDE(s) (blocks 2326, 2328) before terminating(at termination point 2330).

[1451]FIG. 42d is a flowchart of an example of program control stepsperformed by a representative example of BUDGET method 2250 operating inan “administrative reply” mode. Steps shown in FIG. 42d might beperformed, for example, by a VDE user node upon receipt of anadministrative object containing budget-related information. BUDGETmethod 2250 may first prime a Budget administrative and communicationsaudit trail (blocks 2332, 2334). BUDGET method 2250 may then extractrecords and requests from a received administrative object and write thereply record to the VDE secure database (blocks 2336, 2338). The VDEuser node may then save budget administrative and communications audittrail information in an appropriate audit trail UDE(s) (blocks 2340,2341).

[1452] Sometime later, the VDE user node may retrieve the reply recordfrom the secure database and determine what method is required toprocess it (blocks 2344, 2346). The VDE user node may, optionally, primean audit trail (blocks 2342, 2343) to record the results of theprocessing of the reply event. The BUDGET method 2250 may then sendevent(s) contained in the reply record(s) to the REPLY method, and maygenerate/update the secure database records as necessary to, forexample, insert new budget records, delete old budget records and/orapply changes to budget records (blocks 2348, 2350). BUDGET method 2250may then delete the reply record from the secure data base (blocks 2352,2353) before writing the audit trail (if required) (blocks 2354 m 2355)terminating (at terminate point 2356).

[1453] B. REGISTER

[1454]FIGS. 43a-43 d are flowcharts of an example of program controlsteps performed by a representative example of a REGISTER method 2400provided by the preferred embodiment. In this example, the REGISTERmethod 2400 performs the example steps shown in FIG. 43a when operatingin a “use” mode, performs the example steps shown in FIG. 43b whenoperating in an “administrative request” mode, performs the steps shownin FIG. 43c when operating in an “administrative response” mode, andperforms the steps shown in FIG. 43d when operating in an“administrative reply” mode.

[1455] The steps shown in FIG. 43a may be, for example, performed at auser VDE node in response to some action by or on behalf of the user.For example the user may ask to access an object that has not yet been(or is not now) properly registered to her. In response to such a userrequest, the REGISTER method 2400 may prime a Register Audit Trail UDE(blocks 2402, 2404 before determining whether the object being requestedhas already been registered decision block 2406). If the object hasalready been registered (“yes” exit to decision block 2406), theREGISTER method may terminate, at termination point 2408). If the objectis not already registered (“no” exit to decision block 2406), thenREGISTER method 2400 may access the VDE node secure database PERC 808and/or Register MDE (block 2410). REGISTER method 2400 may extract anappropriate Register Record Set from this PERC 808 and/or Register MDE(block 2412), and determine whether all of the required elements arepresent that are needed to register the object (decision block 2414). Ifsome piece(s) is missing (“no” exit to decision block 2414), REGISTERmethod 2400 may queue a Register request record to a communicationmanager and then suspend the REGISTER method until the queued request issatisfied (blocks 2416, 2418). Block 2416 may have the effect ofcommunicating a register request to a VDE distributor, for example. Whenthe request is satisfied and the register request record has beenreceived (block 2420), then the test of decision block 2414 is satisfied(“yes” exit to decision block 2414), and REGISTER method 2400 mayproceed. At this stage, the REGISTER method 2400 may allow the user toselect Register options from the set of method options allowed by PERC808 accessed at block 2410 (block 2422). As one simple example, the PERC808 may permit the user to pay by VISA or MasterCard but not by AmericanExpress; block 2422 may display a prompt asking the user to selectbetween paying using her VISA card and paying using her MasterCard(block 2424). The REGISTER method 2400 preferably validates the userselected registration options and requires the user to select differentoptions if the initial user options were invalid (block 2426, “no” exitto decision block 2428). Once the user has made all requiredregistration option selections and those selections have been validated(“yes” exit to decision block 2428), the REGISTER method 2400 may writean User Registration Table (URT) corresponding to this object and thisuser which embodies the user registration selections made by the useralong with other registration information required by PERC 808 and/orthe Register MDE (blocks 2430, 2432). REGISTER method 2400 may thenwrite a Register audit record into the secure database (blocks 2432,2434) before terminating (at terminate point 2436).

[1456]FIG. 43b shows an example of an “administrative request” mode ofREGISTER method 2400. This Administrative Request Mode may occur on aVDE user system to generate an appropriate administrative object forcommunication to a VDE distributor or other appropriate VDE participantrequesting registration information. Thus, for example, the steps shownin FIG. 43b may be performed as part of the “queue register requestrecord” block 2416 shown in FIG. 43a. To make a Register administrativerequest, REGISTER method 2400 may first prime a communications audittrail (blocks 2440, 2442), and then access the secure database to obtaindata about registration (block 2444). This secure database access may,for example, allow the owner and/or publisher of the object beingregistered to find out demographic, user or other information about theuser. As a specific example, suppose that the object being registered isa spreadsheet software program. The distributor of the object may wantto know what other software the user has registered. For example, thedistributor may be willing to give preferential pricing if the userregisters a “suite” of multiple software products distributed by thesame distributor. Thus, the sort of information solicited by a “userregistration” card enclosed with most standard software packages may besolicited and automatically obtained by the preferred embodiment atregistration time. In order to protect the privacy rights of the user,REGISTER method 2400 may pass such user-specific data through a privacyfilter that may be at least in part customized by the user so the usercan prevent certain information from being revealed to the outside world(block 2446). The REGISTER method 2400 may write the resultinginformation along with appropriate Register Request informationidentifying the object and other appropriate parameters into anadministrative object (blocks 2448, 2450). REGISTER method 2400 may thenpass this administrative object to a communications handler. REGISTERmethod 2400 may then save a communications audit trail (blocks 2452,2454) before terminating (at terminate point 2456)

[1457]FIG. 43c includes REGISTER method 2400 steps that may be performedby a VDE distributor node upon receipt of Register Administrative objectsent by block 2448, FIG. 43b. REGISTER method 2400 in this“administrative responses” mode may prime appropriate audit trails(blocks 2460, 2462), and then may unpack the received administrativeobject and write the associated register request(s) configurationinformation into the secure database (blocks 2464, 2466). REGISTERmethod 2400 may then retrieve the administrative request from the securedatabase and determine which response method to run to process therequest (blocks 2468, 2470). If the user fails to provide sufficientinformation to register the object, REGISTER method 2400 may fail(blocks 2472, 2474). Otherwise, REGISTER method 2400 may send event(s)contained in the appropriate request record(s) to the appropriateresponse method, and generate and write response records and responserequests (e.g., PERC(s) and/or UDEs) to the secure database (blocks2476, 2478). REGISTER method 2400 may then write the appropriateRegister administrative response record into an administrative object(blocks 2480, 2482). Such information may include, for example, one ormore replacement PERC(s) 808, methods, UDE(s), etc. (block 2482). Thisenables, for example, a distributor to distribute limited rightpermissions giving users only enough information to register an object,and then later, upon registration, replacing the limited rightpermissions with wider permissioning scope granting the user morecomplete access to the objects. REGISTER method 2400 may then save thecommunications and response processing audit trail (blocks 2484, 2486),before terminating (at terminate point 2488).

[1458]FIG. 43d shows steps that may be performed by the VDE user nodeupon receipt of the administrative object generated/transmitted by FIG.43c block 2480. The steps shown in FIG. 43d are very similar to thoseshown in FIG. 42d for the BUDGET method administrative reply process.

[1459] C. AUDIT

[1460]FIGS. 44a-44 c are flowcharts of examples of program control stepsperformed by a representative example of an AUDIT method 2520 providedby the preferred embodiment. As in the examples above, the AUDIT method2520 provides three different operational modes in this preferredembodiment example: FIG. 44a shows the steps performed by the AUDITmethod in an “administrative request” mode; FIG. 44b shows stepsperformed by the method in the “administrative response” mode; and FIG.44c shows the steps performed by the method in an “administrative reply”mode.

[1461] The AUDIT method 2520 operating in the “administrative request”mode as shown in FIG. 44a is typically performed, for example, at a VDEuser node based upon some request by or on behalf of the user. Forexample, the user may have requested an audit, or a timer may haveexpired that initiates communication of audit information to a VDEcontent provider or other VDE participant. In the preferred embodiment,different audits of the same overall process may be performed bydifferent VDE participants. A particular “audit” method 2520 invocationmay be initiated for any one (or all) of the involved VDE participants.Upon invocation of AUDIT method 2520, the method may prime an auditadministrative audit trail (thus, in the preferred embodiment, the auditprocessing may itself be audited) (blocks 2522, 2524). The AUDIT method2520 may then queue a request for administrative processing (blocks2526, 2528), and then may save the audit administrative audit trail inthe secure database (blocks 2530, 2532). Sometime later, AUDIT method2520 may prime a communications audit trail (blocks 2534, 2536), and maythen write Audit Administrative Request(s) into one or moreadministrative object(s) based on specific UDE, audit trail UDE(s),and/or administrative record(s) stored in the secure database (blocks2538, 2540). The AUDIT method 2520 may then save appropriate informationinto the communications audit trail (blocks 2542, 2544) beforeterminating (at terminate point 2546).

[1462]FIG. 44b shows example steps performed by a VDE content provider,financial provider or other auditing VDE node upon receipt of theadministrative object generated and communicated by FIG. 44a block 2538.The AUDIT method 2520 in this “administrative response” mode may firstprime an Audit communications and response audit trail (blocks 2550,2552), and may then unpack the received administrative object andretrieve its contained Audit request(s) audit trail(s) and auditrecord(s) for storage into the secured database (blocks 2554, 2556).AUDIT method 2520 may then retrieve the audit request(s) from the securedatabase and determine the response method to run to process the request(blocks 2558, 2560). AUDIT method 2520 may at this stage send event(s)contained in the request record(s) to the appropriate response method,and generate response record(s) and requests based on this method(blocks 2562, 2564). The processing block 2562 may involve acommunication to the outside world.

[1463] For example, AUDIT method 2520 at this point could call anexternal process to perform, for example, an electronic funds transferagainst the user's bank account or some other bank account. The AUDITadministrative response car, if desired, call an external process thatinterfaces VDE to one or more existing computer systems. The externalprocess could be passed the user's account number, PIN, dollar amount,or any other information configured in, or associated with, the VDEaudit trail being processed. The external process can communicate withnon-VDE hosts and use the information passed to it as part of thesecommunications. For example, the external process could generateautomated clearinghouse (ACH) records in a file for submittal to a bank.This mechanism would provide the ability to automatically credit ordebit a bank account in any financial institution. The same mechanismcould be used to communicate with the existing credit card (e.g. VISA)network by submitting VDE based charges against the charge account.

[1464] Once the appropriate Audit response record(s) have beengenerated, AUDIT method 2520 may write an Audit administrative record(s)into an administrative object for communication back to the VDE usernode that generated the Audit request (blocks 2566, 2568). The AUDITmethod 2520 may then save communications and response processing auditinformation in appropriate audit trail(s) (blocks 2570, 2572) beforeterminating (at terminate point 2574).

[1465]FIG. 44c shows an example of steps that may be performed by theAUDIT method 2520 back at the VDE user node upon receipt of theadministrative object generated and sent by FIG. 44b, block 2566. Thesteps 2580-2599 shown in FIG. 44c are similar to the steps shown in FIG.43d for the REGISTER method 2400 in the “administrative reply” mode.Briefly, these steps involve receiving and extracting appropriateresponse records from the administrative object (block 2584), and thenprocessing the received information appropriately to update securedatabase records and perform any other necessary actions (blocks 2595,2596).

[1466] Examples of Event-Driven Content-Based Methods

[1467] VDE methods 1000 are designed to provide a very flexible andhighly modular approach to secure processing. A complete VDE process toservice a “use event” may typically be constructed as a combination ofmethods 1000. As one example, the typical process for reading content orother information from an object 300 may involve the following methods:

[1468] an EVENT method

[1469] a METER method

[1470] a BILLING method

[1471] a BUDGET method

[1472]FIG. 45 is an example of a sequential series of methods performedby VDE 100 in response to an event. In this example, when an eventoccurs, an EVENT method 402 may “qualify” the event to determine whetherit is significant or not. Not all events are significant. For example,if the EVENT method 1000 in a control process dictates that usage is tobe metered based upon number of pages read, then user request “events”for reading less than a page of information may be ignored. In anotherexample, if a system event represents a request to read a certain numberof bytes, and the EVENT method 1000 is part of a control processdesigned to meter paragraphs, then the EVENT method may evaluate theread request to determine how many paragraphs are represented in thebytes requested. This process may involve mapping to “atomic elements”to be discussed in more detail below.

[1473] EVENT method 402 filters out events that are not significant withregard to the specific control method involved. EVENT method 402 maypass on qualified events to a METER process 1404, which meters ordiscards the event based on its own particular criteria.

[1474] In addition, the preferred embodiment provides an optimizationcalled “precheck.” EVENT method/process 402 may perform this “precheck”based on metering, billing and budget information to determine whetherprocessing based on an event will be allowed. Suppose, for example, thatthe user has already exceeded her budget with respect to accessingcertain information content so that no further access is permitted.Although BUDGET method 408 could make this determination, records andprocesses performed by BUDGET method 404 and/or BILLING method 406 mighthave to be “undone” to, for example, prevent the user from being chargedfor an access that was actually denied. It may be more efficient toperform a “precheck” within EVENT method 402 so that fewer transactionshave to be “undone.”

[1475] METER method 404 may store an audit record in a meter “trail” UDE1200, for example, and may also record information related to the eventin a meter UDE 1200. For example, METER method 404 may increment ordecrement a “meter” value within a meter UDE 1200 each time content isaccessed. The two different data structures (meter UDE and meter trailUDE: may be maintained to permit record keeping for reporting purposesto be maintained separately from record keeping for internal operationpurposes, for example.

[1476] Once the event is metered by METER method 404, the metered eventmay be processed by a BILLING method 406. BILLING method 406 determineshow much budget is consumed by the event, and keeps records that areuseful for reconciliation of meters and budgets. Thus, for example.BILLING method 406 may read budget information from a budget UDE, recordbilling information in a billing UDE, and write one or more auditrecords in a billing trail UDE. While some billing trail information mayduplicate meter and/or budget trail information, the billing trailinformation is useful, for example, to allow a content creator 102 toexpect a payment of a certain size, and serve as a reconciliation checkto reconcile meter trail information sent to creator 102 with budgettrail information sent to, for example, an independent budget provider.

[1477] BILLING method 406 may then pass the event on to a BUDGET method408. BUDGET method 408 sets limits and records transactional informationassociated with those limits. For example, BUDGET method 408 may storebudget information in a budget UDE, and may store an audit record in abudget trail UDE. BUDGET method 408 may result in a “budget remaining”field in a budget UDE being decremented by an amount specified byBILLING method 406.

[1478] The information content may be released, or other action taken,once the various methods 402, 404, 406, 408 have processed the event.

[1479] As mentioned above, PERCs 808 in the preferred embodiment may beprovided with “control methods” that in effect “oversee” performance ofthe other required methods in a control process. FIG. 46 shows how therequired methods/processes 402, 404, 406, and 408 of FIG. 45 can beorganized and controlled by a control method 410. Control method 410 maycall, dispatch events, or otherwise invoke the other methods 402, 404,406, 408 and otherwise supervise the processing performed in response toan “event.”

[1480] Control methods operate at the level of control sets 906 withinPERCs 808. They provide structure, logic, and flow of control betweendisparate acquired methods 1000. This mechanism permits the contentprovider to create any desired chain of processing, and also allows thespecific chain of processing to be modified (within permitted limits) bydownstream redistributors. This control structure concept provides greatflexibility.

[1481]FIG. 47 shows an example of an “aggregate” method 412 whichcollects METER method 404, BUDGET method 406 and BILLING method 408 intoan “aggregate” processing flow. Aggregate method 412 may, for example,combine various elements of metering, budgeting and big into a singlemethod 1000. Aggregate method 412 may provide increased efficiency as aresult of processing METER method 404, BUDGET method 406 and BILLINGmethod 408 aggregately, but may decrease flexibility because ofdecreased modularity.

[1482] Many different methods can be in effect simultaneously. FIG. 48shows an example of preferred embodiment event processing using multipleMETER methods 404 and multiple BUDGET methods 1408. Some events may besubject to many different required methods operating independently orcumulatively. For example, in the example shown in FIG. 48, meter method404 a may maintain meter trail and meter information records that areindependent from the meter trail and meter information recordsmaintained by METER method 404 b. Similarly, BUDGET method 408 a maymaintain records independently of those records maintained by BUDGETmethod 408 b. Some events may bypass BILLING method 408 whilenevertheless being processed by meter method 404 a and BUDGET method 408a. A variety of different variations are possible.

[1483] Representative Examples of VDE Methods

[1484] Although methods 1000 can have virtually unlimited variety andsome may even be user-defined, certain basic “use” type methods arepreferably used in the preferred embodiment to control most of the morefundamental object manipulation and other functions provided by VDE 100.For example, the following high level methods would typically beprovided for object manipulation:

[1485] OPEN method

[1486] READ method

[1487] WRITE method

[1488] CLOSE method.

[1489] An OPEN method is used to control opening a container so itscontents may be accessed. A READ method is used to control the access tocontents in a container. A WRITE method is used to control the insertionof contents into a container. A CLOSE method is used to close acontainer that has been opened.

[1490] Subsidiary methods are provided to perform some of the stepsrequired by the OPEN, READ, WRITE and/or CLOSE methods. Such subsidiarymethods may include the following

[1491] ACCESS method

[1492] PANIC method

[1493] ERROR method

[1494] DECRYPT method

[1495] ENCRYPT method

[1496] DESTROY content method

[1497] INFORMATION method

[1498] OBSCURE method

[1499] FINGERPRINT method

[1500] EVENT method.

[1501] CONTENT method

[1502] EXTRACT method

[1503] EMBED method

[1504] METER method

[1505] BUDGET method

[1506] REGISTER method

[1507] BILLING method

[1508] AUDIT method

[1509] An ACCESS method may be used to physically access contentassociated with an opened container (the content can be anywhere). APANIC method may be used to disable at least a portion of the VDE nodeif a security violation is detected. An ERROR method may be used tohandle error conditions. A DECRYPT method is used to decrypt encryptedinformation. An ENCRYPT method is used to encrypt information. A DESTROYcontent method is used to destroy the ability to access specific contentwithin a container. An INFORMATION method is used to provide publicinformation about the contents of a container. An OBSCURE method is usedto devalue content read from an opened container (e.g., to write theword “SAMPLE” over a displayed image). A FINGERPRINT method is used tomark content to show who has released it from the secure container. Anevent method is used to convert events into different events forresponse by other methods.

[1510] Open

[1511]FIG. 49 is a flowchart of an example of preferred embodimentprocess control steps for an example of an OPEN method 1500. DifferentOPEN methods provide different detailed steps. However, the OPEN methodshown in FIG. 49 is a representative example of a relativelyfull-featured “open” method provided by the preferred embodiment. FIG.49 shows a macroscopic view of the OPEN method. FIGS. 49a-49 f aretogether an example of detailed program controlled steps performed toimplement the method shown in FIG. 49.

[1512] The OPEN method process starts with an “open event.” This openevent may be generated by a user application, an operating systemintercept or various other mechanisms for capturing or interceptingcontrol. For example, a user application may issue a request for accessto a particular content stored within the VDE container. As anotherexample, another method may issue a command.

[1513] In the example shown, the open event is processed by a controlmethod 1502. Control method 1502 may call other methods to process theevent. For example, control method 1502 may call an EVENT method 1504, aMETER method 1506, a BILLING method 1508, and a BUDGET method 1510. Notall OPEN control methods necessarily call of these additional methods,but the OPEN method 1500 shown in FIG. 49 is a representative example.

[1514] Control method 1502 passes a description of the open event toEVENT method 1504. EVENT method 1504 may determine, for example, whetherthe open event is permitted and whether the open event is significant inthe sense that it needs to be processed by METER method 1506, BILLINGmethod 1508, anchor BUDGET method 1510 EVENT method 1504 may maintainaudit trail information within an audit trail UDE, and may determinepermissions and significance of the event by using an Event Method DataElement (MDE). EVENT method 1504 may also map the open event into an“atomic element” and count that may be processed by METER method 1506,BILLING method 1508, and/or BUDGET method 1510.

[1515] In OPEN method 1500, once EVENT method 1504 has been called andreturns successfully, control method 1502 then may call METER method1506 and pass the METER method, the atomic element and count returned byEVENT method 1504. METER method 1506 may maintain audit trailinformation in a METER method Audit Trail UDE, and may also maintainmeter information in a METER method UDE. In the preferred embodiment,METER method 1506 returns a meter value to control method 1502 assumingsuccessful completion.

[1516] In the preferred embodiment, control method 1502 upon receivingan indication that METER method 1506 has completed successfully, thencalls BILLING method 1508. Control method 1502 may pass to BILLINGmethod 1508 the meter value provided by METER method 1506. BILLINGmethod 1508 may read and update billing information maintained in aBILLING method map MDE, and may also maintain and update audit trail ina BILLING method Audit Trail UDE. BILLING method 1508 may return abilling amount and a completion code to control method 1502.

[1517] Assuming BILLING method 1508 completes successfully, controlmethod 1502 may pass the billing value provided by BILLING method 1508to BUDGET method 1510. BUDGET method 1510 may read and update budgetinformation within a BUDGET method UDE, and may also maintain audittrail information in a BUDGET method Audit Trail UDE. BUDGET method 1510may return a budget value to control method 1502, and may also return acompletion code indicating whether the open event exceeds the user'sbudget (for this type of event).

[1518] Upon completion of BUDGET method 1510, control method 1502 maycreate a channel and establish read/use control information inpreparation for subsequent calls to the READ method.

[1519]FIGS. 49a-49 f are a more detailed description of the OPEN method1500 example shown in FIG. 49. Referring to FIG. 49a, in response to anopen event, control method 1502 first may determine the identificationof the object to be opened and the identification of the user that hasrequested the object to be opened (block 1520). Control method 1502 thendetermines whether the object to be opened is registered for this user(decision block 1522). It makes this determination at least in part inthe preferred embodiment by reading the PERC 808 and the User RightsTable (URT) element associated with the particular object and particularuser determined by block 1520 (block 1524). If the user is notregistered for this particular object (“no” exit to decision block1522), then control method 1502 may call the REGISTER method for theobject and restart the OPEN method 1500 once registration is complete(block 1526). The REGISTER method block 1526 may be an independentprocess and may be time independent. It may, for example, take arelatively long time to complete the REGISTER method (say if the VDEdistributor or other participant responsible for providing registrationwants to perform a credit check on the user before registering the userfor this particular object).

[1520] Assuming the proper URT for this user and object is present suchthat the object is registered for this user (“yes” exit to decisionblock 1522), control method 1502 may determine whether the object isalready open for this user (decision block 1528 This test may avoidcreating a redundant channel for opening an object that is already open.Assuming the object is not already open (“no” exit to decision block1528), control method 1502 creates a channel and binds appropriate opencontrol elements to it (block 1530). It reads the appropriate opencontrol elements from the secure database (or the container, such as,for example, in the case of a travelling object), and “binds” or “links”these particular appropriate control elements together in order tocontrol opening of the object for this user. Thus, block 1530 associatesan event with one or more appropriate method core(s), appropriate loadmodules, appropriate User Data Elements, and appropriate Method DataElements read from the secure database (or the container) (block 1532).At this point, control method 1502 specifies the open event (whichstarted the OPEN method to begin with), the object ID and user ID(determined by block 1520), and the channel ID of the channel created byblock 1530 to subsequent EVENT method 1504, METER method 1506, BILLINGmethod 1508 and BUDGET method 1510 to provide a secure database“transaction” (block 1536). Before doing so, control method 1502 mayprime an audit process (block 1533) and write audit information into anaudit UDE (block 1534) so a record of the transaction exists even if thetransaction fails or is interfered with.

[1521] The detail steps performed by EVENT method 1504 are set forth onFIG. 49b. EVENT method 1504 may first prime an event audit trail ifrequired, block 1538) which may write to an EVENT Method Audit Trail UDE(block 1540). EVENT method 1504 may then perform the step of mapping theopen event to an atomic element number and event count using a map MDE(block 1542). The EVENT method map MDE may be read from the securedatabase (block 1544). This mapping process performed by block 1542 may,for example, determine whether or not the open event is meterable,billable, or budgetable, and may transform the open event into somediscrete atomic element for metering, billing and/or budgeting. As oneexample, block 1542 might perform a one-to-one mapping between openevents and “open” atomic elements, or it may only provide an open atomicelement for every fifth time that the object is opened. The map block1542 preferably returns the open event, the event count, the atomicelement number, the object ID, and the user ID. This information may bewritten to the EVENT method Audit Trail UDE (block 1546, 1548). In thepreferred embodiment, a test (decision block 1550) is then performed todetermine whether the EVENT method failed. Specifically, decision block1550 may determine whether an atomic element number was generated. If noatomic element number was generated (e.g., meaning that the open eventis not significant for processing by METER method 1506, BILLING method1508 and/or BUDGET method 1510, then EVENT method 1504 may return a“fail” completion code to control method 1502 (“no” exit to decisionblock 1550).

[1522] Control method 1502 tests the completion code returned by EVENTmethod 1504 to determine whether it failed or was successful (decisionblock 1552). If the EVENT method failed (“no” exit to decision block1552), control method 1502 may “roll back” the secure databasetransaction (block 1554) and return itself with an indication that theOPEN method failed (block 1556). In this context, “rolling back” thesecure database transaction means, for example, “undoing” the changesmade to audit trail UDE by blocks 1540, 1548. However, this “roll back”performed by block 1554 in the preferred embodiment does not “undo” thechanges made to the control method audit UDE by blocks 1532, 1534.

[1523] Assuming the EVENT method 1504 completed successfully, controlmethod 1502 then calls the METER method 1506 shown on FIG. 49c. In thepreferred embodiment, METER method 1506 primes the meter audit trail ifrequired (block 1558), which typically involves writing to a METERmethod audit trail UDE (block 1560). METER method 1506 may then read aMETER method UDE from the secure database (block 1562), modify the meterUDE by adding an appropriate event count to the meter value contained inthe meter UDE (block 1564), and then writing the modified meter UDE backto the secure database (block 1562). In other words, block 1564 may readthe meter UDE, increment the meter count it contains, and write thechanged meter UDE back to the secure database. In the preferredembodiment, METER method 1506 may then write meter audit trailinformation to the METER method audit trail UDE if required (blocks1566, 1568). METER method 1506 preferably next performs a test todetermine whether the meter increment succeeded (decision block 1570).METER method 1506 returns to control method 1502 with a completion code(e.g., succeed or fail) and a meter value determined by block 1564.

[1524] Control method 1502 tests whether the METER method succeeded byexamining the completion code, for example (decision block 1572). If theMETER method failed (“no” exit to decision block 1572), then controlmethod 1502 “rolls back” a secure database transaction (block 1574), andreturns with an indication that the OPEN method failed (block 1576).Assuming the METER method succeeded (“yes” exit to decision block 1572.control method 1502 calls the BILLING method 1508 and passes it themeter value prodded by METER method 1506

[1525] An example of steps performed by BILLING method 1508 is set forthin FIG. 49d. BILLING method 1508 may prime a billing audit trail ifrequired (block 1578) by writing to a BILLING method Audit Trail UDEwithin the secure database (block 1580). BILLING method 1508 may thenmap the atomic element number, count and meter value to a billing amountusing a BILLING method map MDE read from the secure database (blocks1582, 1584). Providing an independent BILLING method map MDE containing,for example, price list information, allows separately deliverablepricing for the billing process. The resulting billing amount generatedby block 1582 may be written to the BILLING method Audit Trail UDE(blocks 1586, 1588), and may also be returned to control method 1502. Inaddition, BILLING method 1508 may determine whether a billing amount wasproperly selected by block 1582 (decision block 1590). In this example,the test performed by block 1590 generally requires more than mereexamination of the returned billing amount, since the billing amount maybe changed in unpredictable ways as specified by BILLING method map MDE.Control then returns to control method 1502, which tests the completioncode provided by BILLING method 1508 to determine whether the BILLINGmethod succeeded or failed (block 1592) If the BILLING method failed(“no” exit to decision block 1592), control method 1502 may “roll back”the secure database transaction (block 1594), and return an indicationthat the OPEN method failed (block 1596). Assuming the test performed bydecision block 1592 indicates that the BILLING method succeeded (“yes”exit to decision block 1592), then control method 1502 may call BUDGETmethod 1510.

[1526] Other BILLING methods may use site, user and/or usage informationto establish, for example, pricing information. For example, informationconcerning the presence or absence of an object may be used inestablishing “suite” purchases, competitive discounts, etc. Usage levelsmay be factored into a BILLING method to establish price breaks fordifferent levels of usage. A currency translation feature of a BILLINGmethod may allow purchases and/or pricing in many different currencies.Many other possibilities exist for determining an amount of budgetconsumed by an event that may be incorporated into BILLING methods.

[1527] An example of detailed control steps performed by BUDGET method1510 is set forth in FIG. 49e. BUDGET method 1510 may prime a budgetaudit trail if required by writing to a budget trail MDE (blocks 1598,1600). BUDGET method 1510 may next perform a billing operation by addinga billing amount to a budget value (block 1602). This operation may beperformed, for example, by reading a BUDGET method UDE from the securedatabase, modifying it, and writing it back to the secure database(block 1604). BUDGET method 1510 may then write the budget audit trailinformation to the BUDGET method Audit Trail UDE blocks 1606, 1608).BUDGET method 1510 may finally, in this example, determine whether theuser has run out of budget by determining whether the budget valuecalculated by block 1602 is out of range (decision block 1610). If theuser has run out of budget (“yes” exit to decision block 1610), theBUDGET method 1510 may return a “fail completion” code to control method1502. BUDGET method 1510 then returns to control method 1502, whichtests whether the BUDGET method completion code was successful (decisionblock 1612). If the BUDGET method failed (“no” exit to decision block1612), control method 1502 may “roll back” the secure databasetransaction and itself return with an indication that the OPEN methodfailed (blocks 1614, 1616). Assuming control method 1502 determines thatthe BUDGET method was successful, the control method may perform theadditional steps shown on FIG. 49f. For example, control method 1502 maywrite an open audit trail if required by writing audit information tothe audit UDE that was primed at block 1532 (blocks 1618, 1620). Controlmethod 1502 may then establish a read event processing (block 1622),using the User Right Table and the PERC associated with the object anduser to establish the channel (block 1624). This channel may optionallybe shared between users of the VDE node 600, or may be used only by aspecified user.

[1528] Control method 1502 then, in the preferred embodiment, testswhether the read channel was established successfully (decision block1626). If the read channel was not successfully established (“no” exitto decision block 1626), control method 1502 “rolls back” the secureddatabase transaction and provides an indication that the OPEN methodfailed (blocks 1628, 1630). Assuming the read channel was successfullyestablished (“yes” exit to decision block 1626), control method 1502 may“commit” the secure database transaction (block 1632). This step of“committing” the secure database transaction in the preferred embodimentinvolves, for example, deleting intermediate values associated with thesecure transaction that has just been performed and, in one example,writing changed UDEs and MDEs to the secure database. It is generallynot possible to “roll back” a secure transaction once it has beencommitted by block 1632. Then, control method 1502 may “tear down” thechannel for open processing (block 1634) before terminating (block 1636In some arrangements, such as multi-tasking VDE node environments, theopen channel may be constantly maintained and available for use by anyOPEN method that starts. In other implementations, the channel for openprocessing may be rebuilt and restarted each time an OPEN method starts.

[1529] Read

[1530]FIG. 50, 50a-50 f show examples of process control steps forperforming a representative example of a READ method 1650. ComparingFIG. 50 with FIG. 49 reveals that the same overall high level processingmay typically be performed for READ method 1650 as was described inconnection with OPEN method 1500. Thus, READ method 1650 may call acontrol method 1652 in response to a read event, the control method inturn invoking an EVENT method 1654, a METER method 1656, a BILLINGmethod 1658 and a BUDGET method 1660. In the preferred embodiment, READcontrol method 1652 may request methods to fingerprint and/or obscurecontent before releasing the decrypted content.

[1531]FIGS. 50a-50 e are similar to FIGS. 49a-49 e. Of course, eventhough the same user data elements may be used for both the OPEN method1500 and the READ method 1650, the method data elements for the READmethod may be completely different, and in addition, the user dataelements may provide different auditing, metering, billing and/orbudgeting criteria for read as opposed to open processing

[1532] Referring to FIG. 50f, the READ control method 1652 mustdetermine which key to use to decrypt content if it is going to releasedecrypted content to the user (block 1758). READ control method 1652 maymake this key determination based, in part, upon the PERC 808 for theobject (block 1760). READ control method 1652 may then call an ACCESSmethod to actually obtain the encrypted content to be decrypted (block1762). The content is then decrypted using the key determined by block1758 (block 1764). READ control method 1652 may then determine whether a“fingerprint” is desired (decision block 1766). If fingerprinting of thecontent is desired (“yes” exit of decision block 1766), READ controlmethod 1652 may call the FINGERPRINT method (block 1768). Otherwise,READ control method 1652 may determine whether it is desired to obscurethe decrypted content (decision block 1770). If so, READ control method1652 may call an OBSCURE method to perform this function (block 1772).Finally, READ control method 1652 may commit the secure databasetransaction (block 1774), optionally tear down the read channel (notshown), and terminate block 1776).

[1533] Write

[1534]FIGS. 51, 51a-51 f are flowcharts of examples of process controlsteps used to perform a representative example of a WRITE method 1780 inthe preferred embodiment. WRITE method 1780 uses a control method 1782to call an EVENT method 1784, METER method 1786, BILLING method 1788,and BUDGET method 1790 in this example. Thus, writing information into acontainer (either by overwriting information already stored in thecontainer or adding new information to the container) in the preferredembodiment may be metered, billed and/or budgeted in a manner similar tothe way opening a container and reading from a container can be metered,billed and budgeted. As shown in FIG. 51, the end result of WRITE method1780 is typically to encrypt content, update the container table ofcontents and related information to reflect the new content, and writethe content to the object.

[1535]FIG. 51a for the WRITE control method 1782 is similar to FIG. 49aand FIG. 50a for the OPEN control method and the READ control method,respectively. However, FIG. 51b is slightly different from its open andread counterparts. In particular, block 1820 is performed if the WRITEEVENT method 1784 fails. This block 1820 updates the EVENT method mapMDE to reflect new data. This is necessary to allow information writtenby block 1810 to be read by FIG. 51b READ method block 1678 based on thesame (but now updated EVENT method map MDE.

[1536] Looking at FIG. 51f, once the EVENT, METER, BILLING and BUDGETmethods have returned successfully to WRITE control method 1782, theWRITE control method writes audit information to Audit UDE (blocks 1890,1892), and then determines (based on the PERC for the object and userand an optional algorithm) which key should be used to encrypt thecontent before it is written to the container (blocks 1894, 1896).CONTROL method 1782 then encrypts the content (block 1898) possibly bycalling an ENCRYPT method, and writes the encrypted content to theobject (block 1900). CONTROL method 1782 may then update the table ofcontents (and related information) for the container to reflect thenewly written information (block 1902), commit the secure databasetransaction (block 1904), and return (block 1906).

[1537] Close

[1538]FIG. 52 is a flowchart of an example of process control steps toperform a representative example of a CLOSE method 1920 in the preferredembodiment. CLOSE method 1920 is used to close an open object. In thepreferred embodiment, CLOSE method 1920 primes an audit trail and writesaudit information to an Audit UDE (blocks 1922, 1924). CLOSE method 1920then may destroy the current channel(s) being used to support and/orprocess one or more open objects (block 1926). As discussed above, insome (e.g., multi-user or multi-tasking installations, the step ofdestroying a channel is not needed because the channel may be leftoperating for processing additional objects for the same or differentusers. CLOSE method 1920 also releases appropriate records and resourcesassociated with the object at this time (block 1926). The CLOSE method1920 may then write an audit trail (if required into an Audit UDE(blocks 1928, 1930) before completing.

[1539] Event

[1540]FIG. 53a is a flowchart of example process control steps providedby a more general example of an EVENT method 1940 provided by thepreferred embodiment. Examples of EVENT methods are set forth in FIGS.49b, 50 b and 51 b and are described above. EVENT method 1940 shown inFIG. 53a is somewhat more generalized than the examples above. Like theEVENT method examples above, EVENT method 1940 receives anidentification of the event along with an event count and eventparameters. EVENT method 1940 may first prime an EVENT audit trail (ifrequired) by writing appropriate information to an EVENT method AuditTrail UDE (blocks 1942, 1944). EVENT method 1940 may then obtain andload an EVENT method map DTD from the secure database (blocks 1946,1948). This EVENT method map DTD describes, in this example, the formatof the EVENT method map MDE to be read and accessed immediatelysubsequently (by blocks 1950, 1952). In the preferred embodiment, MDEsand UDEs may have any of various different formats and their formats maybe flexibly specified or changed dynamically depending upon theinstallation, user, etc. The DTD, in effect, describes to the EVENTmethod 1940 how to read from the EVENT method map MDE. DTDs are alsoused to specify how methods should write to MDEs and UDEs, and thus maybe used to implement privacy filters by, for example, preventing certainconfidential user information from being written to data structures thatwill be reported to third parties.

[1541] Block 1950 (“map event to atomic element # and event count usinga Map MDE”) is in some sense the “heart” of EVENT method 1940. This step“maps” the event into an “atomic element number” to be responded to bysubsequently called methods. An example of process control stepsperformed by a somewhat representative example of this “mapping” step1950 is shown in FIG. 53b.

[1542] The FIG. 53b example shows the process of converting a READ eventthat is associated with requesting byte range 1001-1500 from a specificpiece of content into an appropriate atomic element. The example EVENTmethod mapping process (block 1950 in FIG. 53a) can be detailed as therepresentative process shown in FIG. 53b.

[1543] EVENT method mapping process 1950 may fist look up the event code(READ) in the EVENT method MDE (1952) using the EVENT method map DTD(1948 to determine the structure and contents of the MDE. A test mightthen be performed to determine if the event code was found in the MDE(1956), and if not (“No” branch), the EVENT method mapping process maythe terminate (1958) without mapping the event to an atomic elementnumber and count. If the event was found in the MDE (“Yes” branch), theEVENT method mapping process may then compare the event range (e.g.,bytes 1001-1500) against the atomic element to event range mapping tablestored in the MDE (block 1960). The comparison might yield one or moreatomic element numbers or the event range might not be found in themapping table. The result of the comparison might then be tested (block1962) to determine if any atomic element numbers were found in thetable. If not (“No” branch), the EVENT method mapping process mayterminate without selecting any atomic element numbers or counts (1964).If the atomic element numbers were found, the process might thencalculate the atomic element count from the event range (1966). In thisexample, the process might calculate the number of bytes requested bysubtracting the upper byte range from the lower byte range (e.g.,1500−1001+1=500). The example EVENT method mapping process might thenterminate (block 1968) and return the atomic element number(s) andcounts.

[1544] EVENT method 1940 may then write an EVENT audit trail if requiredto an EVENT method Audit Trail UDE (block 1970, 1972). EVENT method 1940may then prepare to pass the atomic element number and event count tothe calling CONTROL method (or other control process) (at exit point1978). Before that, however, EVENT method 1940 may test whether anatomic element was selected (decision block 1974). If no atomic elementwas selected, then the EVENT method may be failed (block 1974). This mayoccur for a number of reasons. For example, the EVENT method may fail tomap an event into an atomic element if the user is not authorized toaccess the specific areas of content that the EVENT method MDE does notdescribe. This mechanism could be used, for example, to distributecustomized versions of a piece of content and control access to thevarious versions in the content object by altering the EVENT method MDEdelivered to the user. A specific use of this technology might be tocontrol the distribution of different language e.g., English, French,Spanish versions of a piece of content.

[1545] Billing

[1546]FIG. 53c is a flowchart of an example of process control stepsperformed by a BILLING method 1980. Examples of BILLING methods are setforth in FIGS. 49d, 50 d, and 51 d and are described above. BILLINGmethod 1980 shown in FIG. 53c is somewhat more generalized than theexamples above. Like the BILLING method examples above, BILLING method1980 receives a meter value to determine the amount to bill. BILLINGmethod 1980 may first prime a BILLING audit trail (if required) bywriting appropriate information to the BILLING method Audit Trail UDE(blocks 1982, 1984). BILLING method 1980 may then obtain and load aBILLING method map DTD from the secure database (blocks 1985, 1986),which describes the BILLING method map MDE (e.g., a price list, table,or parameters to the biking amount calculation algorithm) that should beused by this BILLING method. The BILLING method map MDE may be deliveredeither as part of the content object or as a separately deliverablecomponent that is combined with the control information at registration.

[1547] The BILLING method map MDE in this example may describe thepricing algorithm that should be used in this BILLING method (e.g., bill$0 001 per byte of content released). Block 1988 (“Map meter value tobilling amount”) functions in the same manner as block 1950 of the EVENTmethod; it maps the meter value to a billing value. Process step 1988may also interrogate the secure database (as limited by the privacyfilter) to determine if other objects or information (e.g., userinformation) are present as part of the BILLING method algorithm.

[1548] BILLING method 1980 may then write a BILLING audit trail ifrequired to a BILLING method Audit Trail UDE (block 1990, 1992), and mayprepare to return the billing amount to the calling CONTROL method (orother control process). Before that, however, BILLING method 1980 maytest whether a billing amount was determined (decision block 1994). Ifno billing amount was determined, then the BILLING method may be failed(block 1996). This may occur if the user is not authorized to access thespecific areas of the pricing table that the BILLING method MDEdescribes (e.g., you may purchase not more than $100.00 of informationfrom this content object

[1549] Access

[1550]FIG. 54 is a flowchart of an example of program control stepsperformed by an ACCESS method 2000. As described above, an ACCESS methodmay be used to access content embedded in an object 300 so it can bewritten to, read from, or otherwise manipulated or processed. In manycases, the ACCESS method may be relatively trivial since the object may,for example, be stored in a local storage that is easily accessible.However, in the general case, an ACCESS method 2000 must go through amore complicated procedure in order to obtain the object. For example,some objects (or parts of objects) may only be available at remote sitesor may be provided in the form of a real-time download or feed (e.g., inthe case of broadcast transmissions). Even if the object is storedlocally to the VDE node, it may be stored as a secure or protectedobject so that it is not directly accessible to a calling process.ACCESS method 2000 establishes the connections, routings, and securityrequisites needed to access the object. These steps may be performedtransparently to the calling process so that the calling process onlyneeds to issue an access request and the particular ACCESS methodcorresponding to the object or class of objects handles all of thedetails and logistics involved in actually accessing the object.

[1551] ACCESS method 2000 may first prime an ACCESS audit trail (ifrequired) by writing to an ACCESS Audit Trail LODE blocks 2002, 2004).ACCESS method 2000 may then read and load an ACCESS method DTD in orderto determine the format of an ACCESS MDE (blocks 2006, 2008). The ACCESSmethod MDE specifies the source and routing information for theparticular object to be accessed in the preferred embodiment. Using theACCESS method DTD, ACCESS method 2000 may load the correction parameters(e.g., by telephone number, account ID, password and/or a request scriptin the remote resource dependent language).

[1552] ACCESS method 2000 reads the ACCESS method MDE from the securedatabase, reads it in accordance with the ACCESS method DTD, and loadsencrypted content source and routing information based on the MDE(blocks 2010, 2012). This source and routing information specifies thelocation of the encrypted content. ACCESS method 2000 then determineswhether a connection to the content is available (decision block 2014).This “connection” could be, for example, an on-line connection to aremote site, a real-time information feed, or a path to asecure/protected resource, for example. If the connection to the contentis not currently available (“No” exit of decision block 2014), thenACCESS method 2000 takes steps to open the connection (block 2016). Ifthe connection fails (e.g., because the user is not authorized to accessa protected secure resource), then the ACCESS method 2000 returns with afailure indication (termination point 2018). If the open connectionsucceeds, on the other hand, then ACCESS method 2000 obtains theencrypted content (block 2020). ACCESS method 2000 then writes an ACCESSaudit trail if required to the secure database ACCESS method Audit TrailUDE (blocks 2022, 2024), and then terminates (terminate point 2026).

[1553] Decrypt and Encrypt

[1554]FIG. 55a is a flowchart of an example of process control stepsperformed by a representative example of a DECRYPT method 2030 providedby the preferred embodiment. DECRYPT method 2030 in the preferredembodiment obtains or derives a decryption key from an appropriate PERC808, and uses it to decrypt a block of encrypted content. DECRYPT method2030 is passed a block of encrypted content or a pointer to where theencrypted block is stored. DECRYPT 2030 selects a key number from a keyblock (block 2032). For security purposes, a content object may beencrypted with more than one key. For example, a movie may have thefirst 10 minutes encrypted using a first key, the second 10 minutesencrypted with a second key, and so on. These keys are stored in a PERC808 in a structure called a “key block.” The selection process involvesdetermining the correct key to use from the key block in order todecrypt the content. The process for this selection is similar to theprocess used by EVENT methods to map events into atomic element numbers.DECRYPT method 2030 may then access an appropriate PERC 808 from thesecure database 610 and loads a key (or “seed”) from a PERC (blocks2034, 2036). This key information may be the actual decryption key to beused to decrypt the content, or it may be information from which thedecryption key may be at least in part derived or calculated. Ifnecessary, DECRYPT method 2030 computes the decryption key based on theinformation read from PERC 808 at block 2034 (block 2038). DECRYPTmethod 2030 then uses the obtained and/or calculated decryption key toactually decrypt the block of encrypted information (block 2040).DECRYPT method 2030 outputs the decrypted block (or the pointerindicating where it may be found), and terminates (termination point2042).

[1555]FIG. 55b is a flowchart of an example of process control stepsperformed by a representative example of an ENCRYPT method 2050. ENCRYPTmethod 2050 is passed as an input, a block of information to encrypt (ora pointer indicating where it may be found). ENCRYPT method 2050 thenmay determine an encryption key to use from a key block (block 2052).The encryption key selection makes a determination if a key for aspecific block of content to be written already exists in a key blockstored in PERC 808. If the key already exists in the key block, then theappropriate key number is selected. If no such key exists in the keyblock, a new key is calculated using an algorithm appropriate to theencryption algorithm. This key is then stored in the key block of PERC808 so that DECRYPT method 2030 may access the key in order to decryptthe content stored in the content object. ENCRYPT method 2050 thenaccesses the appropriate PERC to obtain, derive and/or compute anencryption key to be used to encrypt the information block (blocks 2054,2056, 2058, which are similar to FIG. 55a blocks 2034, 2036, 2038).ENCRYPT method 2050 then actually encrypts the information block usingthe obtained and/or derived encryption key (block 2060) and outputs theencrypted information block or a pointer where it can be found beforeterminating (termination point 2062).

[1556] Content

[1557]FIG. 56 is a flowchart of an example of process control stepsperformed by a representative of a CONTENT method 2070 provided by thepreferred embodiment. CONTENT method 2070 in the preferred embodimentbuilds a “synopsis” of protected content using a secure process. Forexample, CONTENT method 2070 may be used to derive unsecure (“public”)information from secure content. Such derived public information mightinclude, for example, an abstract, an index, a table of contents, adirectory of files, a schedule when content may be available, orexcerpts such as for example, a movie “trailer.”

[1558] CONTENT method 2070 begins by determining whether the derivedcontent to be provided must be derived from secure contents, or whetherit is already available in the object in the form-of static values(decision block 2070). Some objects may, for example, contain prestoredabstracts, indexes, tables of contents, etc., provided expressly for thepurpose of being extracted by the CONTENT method 2070. If the objectcontains such static values (“static” exit to decision block 2072), thenCONTENT method 2070 may simply read this static value contentinformation from the object (block 2074), optionally decrypt, andrelease this content description (block 2076). If, on the other hand,CONTENT method 2070 must derive the synopsis/content description fromthe secure object (“derived” exit to decision block 2072), then theCONTENT method may then securely read information from the containeraccording to a synopsis algorithm to produce the synopsis (block 2078).

[1559] Extract and Embed

[1560]FIG. 57a is a flowchart of an example of process control stepsperformed by a representative example of an EXTRACT method 2080 providedby the preferred embodiment. EXTRACT method 2080 is used to copy orremove content from an object and place it into a new object. In thepreferred embodiment, the EXTRACT method 2080 does not involve anyrelease of content, but rather simply takes content from one containerand places it into another container, both of which may be secure.Extraction of content differs from release in that the content is neverexposed outside a secure container. Extraction and Embedding arecomplementary functions; extract takes content from a container andcreates a new container containing the extracted content and anyspecified control information associated with that content. Embeddingtakes content that is already in a container and stores it (or thecomplete object) in another container directly and/or by reference,integrating the control information associated with existing contentwith those of the new content.

[1561] EXTRACT method 2080 begins by priming an Audit UDE (blocks 2082,2084). EXTRACT method then calls a BUDGET method to make sure that theuser has enough budget for (and is authorized to) extract content fromthe original object (block 2086). If the users budget does not permitthe extraction (“no” exit to decision block 2088), then EXTRACT method2080 may write a failure audit record (block 2090), and terminate(termination point 2092). If the user's budget permits the extraction(“yes” exit to decision block 2088), then the EXTRACT method 2080creates a copy of the extracted object with specified rules and controlinformation (block 2094). In the preferred embodiment, this stepinvolves calling a method that actually controls the copy. This step mayor may not involve decryption and encryption, depending on theparticular the PERC 808 associated with the original object, forexample. EXTRACT method 2080 then checks whether any control changes arepermitted by the rights authorizing the extract to begin with (decisionblock 2096). In some cases, the extract rights require an exact copy ofthe PERC 808 associated with the original object (or a PERC included forthis purpose) to be placed in the new (destination) container (“no” exitto decision block 2096). If no control changes are permitted, thenextract method 2080 may simply write audit information to the Audit UDE(blocks 2098, 2100) before terminating (terminate point 2102). If, onthe other hand, the extract rights permit the user to make controlchanges (“yes” to decision block 2096), then EXTRACT method 2080 maycall a method or load module that solicits new or changed controlinformation (e.g., from the user, the distributor who created/grantedextract rights, or from some other source) from the user (blocks 2104,2106). EXTRACT method 2080 may then call a method or load module tocreate a new PERC that reflects these user-specified control information(block 2104). This new PERC is then placed in the new (destination)object, the auditing steps are performed, and the process terminates.

[1562]FIG. 57b is an example of process control steps performed by arepresentative example of an EMBED method 2110 provided by the preferredembodiment. EMBED method 2110 is similar to EXTRACT method 2080 shown inFIG. 51a. However, the EMBED method 2110 performs a slightly differentfunction—it writes an object (or reference) into a destinationcontainer. Blocks 2112-2122 shown in FIG. 57b are similar to blocks2082-2092 shown in FIG. 57a. At block 2124, EMBED method 2110 writes thesource object into the destination container, and may at the same timeextract or change the control information of the destination container.One alternative is to simply leave the control information of thedestination container alone, and include the full set of controlinformation associated with the object being embedded in addition to theoriginal container control information. As an optimization, however, thepreferred embodiment provides a technique whereby the controlinformation associated with the object being embedded are “abstracted”and incorporated into the control information of the destinationcontainer. Block 2124 may call a method to abstract or change thiscontrol information. EMBED method 2110 then performs steps 2126-2130which are similar to steps 2096, 2104, 2106 shown in FIG. 57a to allowthe user, if authorized, to change and/or specify control informationassociated with the embedded object and/or destination container. EMBEDmethod 2110 then writes audit information into an Audit UDE (blocks2132, 2134), before terminating (at termination point 2136).

[1563] Obscure

[1564]FIG. 58a is a flowchart of an example of process control stepsperformed by a representative example of an OBSCURE method 2140 providedby the preferred embodiment. OBSCURE method 2140 is typically used torelease secure content in devalued form. For example, OBSCURE method2140 may release a high resolution image in a lower resolution so that aviewer can appreciate the image but not enjoy its full value. As anotherexample, the OBSCURE method 2140 may place an obscuring legend (e.g.,“COPY,” “PROOF,” etc.) across an image to devalue it. OBSCURE method2140 may “obscure” text, images, audio information, or any other type ofcontent.

[1565] OBSCURE method 2140 first calls an EVENT method to determine ifthe content is appropriate and in the range to be obscured (block 2142).If the content is not appropriate for obscuring, the OBSCURE methodterminates (decision block 2144 “no” exit, terminate point 2146).Assuming that the content is to be obscured (“yes” exit to decisionblock 2144), then OBSCURE method 2140 determines whether it haspreviously been called to obscure this content (decision block 2148).Assuming the OBSCURE 2140 has not previously called for thisobject/content (“yes” exit to decision block 2148), the OBSCURE method2140 reads an appropriate OBSCURE method MDE from the secure databaseand loads an obscure formula and/or pattern from the MDE (blocks 2150,2152). The OBSCURE method 2140 may then apply the appropriate obscuretransform based on the patters and/or formulas loaded by block 2150(block 2154). The OBSCURE method then may terminate (terminate block2156).

[1566] Fingerprint

[1567]FIG. 58b is a flowchart of an example of process control stepsperformed by a representative example of a FINGERPRINT method 2160provided by the preferred embodiment. FINGERPRINT method 2160 in thepreferred embodiment operates to “mark” released content with a“fingerprint” identification of who released the content and/or checkfor such marks. This allows one to later determine who releasedunsecured content by examining the content. FINGERPRINT method 2160 may,for example, insert a user ID within a datastream representing audio,video, or binary format information. FINGERPRINT method 2160 is quitesimilar to OBSCURE method 2140 shown in FIG. 58a except that thetransform applied by FINGERPRINT method block 2174 “fingerprints” thereleased content rather than obscuring it.

[1568]FIG. 58c shows an example of a “fingerprinting” procedure 2160that inserts into released content “fingerprints” 2161 that identify theobject and/or property and/or the user that requested the releasedcontent and/or the date and time of the release and/or otheridentification criteria of the released content.

[1569] Such fingerprints 2161 can be “buried”—that is inserted in amanner that hides the fingerprints from typical users, sophisticated“hackers,” and/or from all users, depending on the file format, thesophistication and/or variety of the insertion algorithms, and on theavailability of original, non-fingerprinted content (for comparison forreverse engineering of algorithm(s), Inserted or embedded fingerprints2161, in a preferred embodiment, may be at least in part encrypted tomake them more secure. Such encrypted fingerprints 2161 may be embeddedwithin released content provided in “clear” (plaintext) form.

[1570] Fingerprints 2161 can be used for a variety of purposesincluding, for example, the often related purposes of proving misuse ofreleased materials and proving the source of released content. Softwarepiracy is a particularly good example where fingerprinting can be veryuseful. Fingerprinting can also help to enforce content providers'rights for most types of electronically delivered information includingmovies, audio recordings, multimedia, information databases, andtraditional “literary” materials. Fingerprinting is a desirablealternative or addition to copy protection.

[1571] Most piracy of software applications, for example, occurs notwith the making of an illicit copy by an individual for use on anotherof the individual's own computers, but rather in giving a copy toanother party. This often starts a chain (or more accurately a pyramid)of illegal copies, as copies are handed from individual to individual.The fear of identification resulting from the embedding of a fingerprint2161 will likely dissuade most individuals from participating, as manycurrently do, in widespread, “casual” piracy. In some cases, content maybe checked for the presence of a fingerprint by a fingerprint method tohelp enforce content providers' rights.

[1572] Different fingerprints 2161 can have different levels of security(e.g., one fingerprint 2161(1) could be readable/identifiable bycommercial concerns, while another fingerprint 2161(2) could be readableonly by a more trusted agency. The methods for generating the moresecure fingerprint 2161 might employ more complex encryption techniques(e.g., digital signatures) and/or obscuring of location methodologies.Two or more fingerprints 2161 can be embedded in different locationsand/or using different techniques to help protect fingerprintedinformation against hackers. The more secure fingerprints might only beemployed periodically rather than each time content release occurs, ifthe technique used to provide a more secure fingerprint involves anundesired amount of additional overhead. This may nevertheless beeffective since a principal objective of fingerprinting isdeterrence—that is the fear on the part of the creator of an illicitcopy that the copying will be found out.

[1573] For example, one might embed a copy of a fingerprint 2161 whichmight be readily identified by an authorized party—for example adistributor, service personal, client administrator, or clearinghouseusing a VDE electronic appliance 600. One might embed one or moreadditional copies or variants of a fingerprint 2161 (e.g., fingerprintscarrying information describing some or all relevant identifyinginformation) and this additional one or more fingerprints 2161 might bemaintained in a more secure manner.

[1574] Fingerprinting can also protect privacy concerns. For example,the algorithm and/or mechanisms needed to identify the fingerprint 2161might be available only through a particularly trusted agent.

[1575] Fingerprinting 2161 can take many forms. For example, in animage, the color of every N pixels (spread across an image, or spreadacross a subset of the image) might be subtly shifted in a visuallyunnoticeable manner (at least according to the normal, unaidedobserver). These shifts could be interpreted by analysis of the image(with or without access to the original image), with each occurrence orlack of occurrence of a shift in color (or greyscale) being one or morebinary “on or off” bits for digital information storage. The N pixelsmight be either consistent, or alternatively, pseudo-random in order(but interpretable, at least in part, by a object creator, objectprovider, client administrator, and/or VDE administrator).

[1576] Other modifications of an image (or moving image, audio, etc.)which provide a similar benefit (that is, storing information in a formthat is not normally noticeable as a result of a certain modification ofthe source information) may be appropriate, depending on theapplication. For example, certain subtle modifications in the frequencyof stored audio information can be modified so as to be normallyunnoticeable to the listener while still being readable with the propertools. Certain properties of the storage of information might bemodified to provide such slight but interpretable variations in polarityof certain information which is optically stored to achieve similarresults. Other variations employing other electronic, magnetic, and/oroptical characteristic may be employed.

[1577] Content stored in files that employ graphical formats, such asMicrosoft Windows word processing files, provide significantopportunities for “burying” a fingerprint 2161. Content that includesimages and/or audio provides the opportunity to embed fingerprints 2161that may be difficult for unauthorized individuals to identify since, inthe absence of an “unfingerprinted” original for purposes of comparison,minor subtle variations at one or more time instances in audiofrequencies, or in one or more video images, or the like, will be inthemselves undiscernible given the normally unknown nature of theoriginal and the large amounts of data employed in both image and sounddata (and which is not particularly sensitive to minor variations). Withformatted text documents, particularly those created with graphical wordprocessors (such as Microsoft Windows or Apple MacIntosh word processorsand their DOS and Unix equivalents), fingerprints 2161 can normally beinserted unobtrusively into portions of the document data representationthat are not normally visible to the end user (such as in a header orother non-displayed data field).

[1578] Yet another form of fingerprinting, which may be particularlysuitable for certain textual documents, would employ and control theformation of characters for a given font. Individual characters may havea slightly different visual formation which connotes certain“fingerprint” information. This alteration of a given character's formwould be generally undiscernible, in part because so many slightvariations exist in versions of the same font available from differentsuppliers, and in part because of the smallness of the variation. Forexample, in a preferred embodiment, a program such as Adobe Type Aligncould be used which, in its off-the-shelf versions, supports the abilityof a user to modify font characters in a variety of ways. Themathematical definition of the font character is modified according tothe user's instructions to produce a specific set of modifications to beapplied to a character or font. Information content could be used in ananalogous manner (as an alternative to user selections) to modifycertain or all characters too subtly for user recognition under normalcircumstances but which nevertheless provide appropriate encoding forthe fingerprint 2161. Various subtly different versions of a givencharacter might be used within a single document so as to increase theability to carry transaction related font fingerprinted information.

[1579] Some other examples of applications for fingerprinting mightinclude:

[1580] 1. In software programs, selecting certain interchangeable codefragments in such a way as to produce more or less identical operation,but on analysis, differences that detail fingerprint information.

[1581] 2. With databases, selecting to format certain fields, such asdates, to appear in different ways.

[1582] 3. In games, adjusting backgrounds, or changing order of certainevents, including noticeable or very subtle changes in timing and/orordering of appearance of game elements, or slight changes in the lookof elements of the game.

[1583] Fingerprinting method 2160 is typically performed if at all atthe point at which content is released from a content object 300.However, it could also be performed upon distribution of an object to“mark” the content while still in encrypted form. For example, anetwork-based object repository could embed fingerprints 2161 into thecontent of an object before transmitting the object to the requester,the fingerprint information could identify a content requester/end user.This could help detect “spoof” electronic appliances 600 used to releasecontent without authorization.

[1584] Destroy

[1585]FIG. 59 is a flowchart of an example of process control stepsperformed by a representative performed by a DESTROY method 2180provided by the preferred embodiment. DESTROY method 2180 removes theability of a user to use an object by destroying the URT the userrequires to access the object. In the preferred embodiment, a DESTROYmethod 2180 may first write audit information to an Audit UDE (blocks2182, 2184). DESTROY method 2180 may than call a WRITE and/or ACCESSmethod to write information which will corrupt (and thus destroy) theheader and/or other important parts of the object (block 2186). DESTROYmethod 2180 may then mark one or more of the control structures (e.g.,the URT) as damaged by writing appropriate information to the controlstructure (blocks 2188, 2190). DESTROY method 2180, finally, may writeadditional audit information to Audit UDE (blocks 2192, 2194) beforeterminating (terminate point 2196).

[1586] Panic

[1587]FIG. 60 is a flowchart of an example of process control stepsperformed by a representative example of a PANIC method 2200 provided bythe preferred embodiment. PANIC method 2200 may be called when asecurity violation is detected. PANIC method 2200 may prevent the userfrom further accessing the object currently being accessed by, forexample, destroying the channel being used to access the object andmarking one or more of the control structures (e.g., the URT) associatedwith the user and object as damaged (blocks 2206, and 2208-2210,respectively). Because the control structure is damaged, the VDE nodewill need to contact an administrator to obtain a valid controlstructure(s) before the user may access the same object again. When theVDE node contacts the administrator, the administrator may requestinformation sufficient to satisfy itself that no security violationoccurred, or if a security violation did occur, take appropriate stepsto ensure that the security violation is not repeated.

[1588] Meter

[1589]FIG. 61 is a flowchart of an example of process control stepsperformed by a representative example of a METER method provided by thepreferred embodiment. Although METER methods were described above inconnection with FIGS. 49, 50 and 51, the METER method 2220 shown in FIG.61 is possibly a somewhat more representative example. In the preferredembodiment, METER method 2220 first primes an Audit Trail by accessing aMETER Audit Trail UDE (blocks 2222, 2224). METER method 2220 may thenread the DTD for the Meter UDE from the secure database (blocks 2226,2228). METER method 2220 may then read the Meter UDE from the securedatabase (blocks 2230, 2232). METER method 2220 next may test theobtained Meter UDE to determine whether it has expired (decision block2234). In the preferred embodiment, each Meter UDE may be marked with anexpiration date. If the current date/time is later than the expirationdate of the Meter UDE (“yes” exit to decision block 2234), then theMETER method 2220 may record a failure in the Audit Record and terminatewith a failure condition (block 2236, 2238).

[1590] Assuming the Meter UDE is not yet expired, the meter method 2220may update it using the atomic element and event count passed to theMETER method from, for example, an EVENT method (blocks 2239, 2240). TheMETER method 2220 may then save the Meter Use Audit Record in the MeterAudit Trail UDE (blocks 2242, 2244), before terminating (at terminatepoint 2246).

[1591] Additional Security Features Provided by the Preferred Embodiment

[1592] VDE 100 provided by the preferred embodiment has sufficientsecurity to help ensure that it cannot be compromised short of asuccessful “brute force attack,” and so that the time and cost tosucceed in such a “brute force attack” substantially exceeds any valueto be derived. In addition, the security provided by VDE 100compartmentalizes the internal workings of VDE so that a successful“brute force attack” would compromise only a strictly bounded subset ofprotected information, not the entire system.

[1593] The following are among security aspects and features provided bythe preferred embodiment:

[1594] security of PPE 650 and the processes it performs

[1595] security of secure database 610

[1596] security of encryption/decryption performed by PPE 650

[1597] key management security of encryption/decryption keys and sharedsecrets

[1598] security of authentication/external communications

[1599] security of secure database backup

[1600] secure transportability of VDE internal information betweenelectronic appliances 600

[1601] security of permissions to access VDE secure information

[1602] security of VDE objects 300

[1603] integrity of VDE security.

[1604] Some of these security aspects and considerations are discussedabove. The following provides an expanded discussion of preferredembodiment security features not fully addressed elsewhere.

[1605] Management of Keys and Shared Secrets

[1606] VDE 100 uses keys and shared secrets to provide security. Thefollowing key usage features are provided by the preferred embodiment:

[1607] different cryptosystem/key types

[1608] secure key length

[1609] key generation

[1610] key “convolution” and key “aging.”

[1611] each of these types are discussed below.

[1612] A Public-Key and Symetric Key Cryptosystems

[1613] The process of disguising or transforming information to hide itssubstance is called encryption. Encryption produces “ciphertext.”Reversing the encryption process to recover the substance from theciphertext is called “decryption.” A cryptographic algorithm is themathematical function used for encryption and decryption.

[1614] Most modern cryptographic algorithms use a “key.” The “key”specifies one of a family of transformations to be provided. Keys allowa standard, published and tested cryptographic algorithm to be usedwhile ensuring that specific transformations performed using thealgorithm are kept secret. The secrecy of the particular transformationsthus depends on the secrecy of the key, not on the secrecy of thealgorithm.

[1615] There are two general forms of key-based algorithms, either orboth of which may be used by the preferred embodiment PPE 650:

[1616] symmetric; and

[1617] public-key (“PK”).

[1618] Symmetric algorithms are algorithms where the encryption key canbe calculated from the decryption key and vice versa. In many suchsystems, the encryption and decryption keys are the same. Thealgorithms, also called “secret-key”, “single key” or “shared secret”algorithms, require a sender and receiver to agree on a key beforeciphertext produced by a sender can be decrypted by a receiver. This keymust be kept secret. The security of a symmetric algorithm rests in thekey: divulging the key means that anybody could encrypt and decryptinformation in such a cryptosystem. See Schneier, Applied Cryptographyat Page 3. Some examples of symmetric key algorithms that the preferredembodiment may use include DES, Skipjack/Clipper, IDEA, RC2, and RC4.

[1619] In public-key cryptosystems, the key used for encryption isdifferent from the key used for decryption. Furthermore, it iscomputationally infeasible to derive one key from the other. Thealgorithms used in these cryptosystems are called “public key” becauseone of the two keys can be made public without endangering the securityof the other key. They are also sometimes called “asymmetric”cryptosystems because they use different keys for encryption anddecryption. Examples of public-key algorithms include RSA. El Gamal andLUC.

[1620] The preferred embodiment PPE 650 may operate based on onlysymmetric key cryptosystems, based on public-key cryptosystems, or basedon both symmetric key cryptosystems and public-key cryptosystems. VDE100 does not require any specific encryption algorithms; thearchitecture provided by the preferred embodiment may support numerousalgorithms including PK and/or secret key (non PK) algorithms. In somecases, the choice of encryption/decryption algorithm will be dependenton a number of business decisions such as cost, market demands,compatibility with other commercially available systems, export laws,etc.

[1621] Although the preferred embodiment is not dependent on anyparticular type of cryptosystem or encryption/decryption algorithm(s),the preferred example uses PK cryptosystems for secure communicationsbetween PPEs 650, and uses secret key cryptosystems for “bulk”encryption/decryption of VDE objects 300. Using secret key cryptosystems(e.g., DES implementations using multiple keys and multiple passes,Skipjack, RC2, or RC4, for “bulk” encryption/decryption providesefficiencies in encrypting and decrypting large quantities ofinformation, and also permits PPEs 650 without PK-capability to dealwith VDE objects 300 in a variety of applications. Using PKcryptosystems for communications may provide advantages such aseliminating reliance on secret shared external communication keys toestablish communications, allowing for a challenge/response that doesn'trely on shared internal secrets to authenticate PPEs 650, and allowingfor a publicly available “certification” process without reliance onshared secret keys.

[1622] Some content providers may wish to restrict use of their contentto PK implementations. This desire can be supported by making theavailability of PK capabilities, and the specific nature or type of PKcapabilities, in PPEs 650 a factor in the registration of VDE objects300, for example, by including a requirement in a REGISTER method forsuch objects in the form of a load module that examines a PPE 650 forspecific or general PK capabilities before allowing registration tocontinue.

[1623] Although VDE 100 does not require any specific algorithm, it ishighly desirable that all PPEs 650 are capable of using the samealgorithm for bulk encryption/decryption. If the bulkencryption/decryption algorithm used for encrypting VDE objects 300 isnot standardized, then it is possible that not all VDE electronicappliances 600 will be capable of handling all VDE objects 300.Performance differences will exist between different PPEs 650 andassociated electronic appliances 600 if standardized bulkencryption/decryption algorithms are not implemented in whole or in partby hardware-based encrypt/decrypt engine 522, and instead areimplemented in software. In order to support algorithms that are notimplemented in whole or in part by encrypt/decrypt engine 522, acomponent assembly that implements such an algorithm must be availableto a PPE 650.

[1624] B. Key Length

[1625] Increased key length may increase security. A “brute-force”attack of a cryptosystem involves trying every possible key. The longerthe key, the more possible keys there are to try. At some key length,available computation resources will require an impractically largeamount of time for a “brute force” attacker to try every possible key.

[1626] VDE 100 provided by the preferred embodiment accommodates and canuse many different key lengths. The length of keys used by VDE 100 inthe preferred embodiment is determined by the algorithm(s) used forencryption/decryption, the level of security desired, and throughputrequirements. Longer keys generally require additional processing powerto ensure fast encryption/decryption response times. Therefore, there isa tradeoff between (a) security, and (b) processing time and/orresources. Since a hardware-based PPE encrypt/decrypt engine 522 mayprovide faster processing than software-based encryption/decryption, thehardware-based approach may, in general, allow use of longer keys.

[1627] The preferred embodiment may use a 1024 bit modulus (key) RSAcryptosystem implementation for PK encryption/decryption, and may use56-bit DES for “bulk” encryption/(decryption. Since the 56-bit keyprovided by standard DES may not be long enough to provide sufficientsecurity for at least the most sensitive VDE information, multiple DESencryptions using multiple passes and multiple DES keys may be used toprovide additional security. DES can be made significantly more secureif operated in a manner that uses multiple passes with different keys.For example, three passes with 2 or 3 separate keys is much more securebecause it effectively increases the length of the key. RC2 and RC4(alternatives to DES) can be exported for up to 40-bit key sizes, butthe key size probably needs to be much greater to provide even DES levelsecurity. The 80-bit key length provided by NSA's Skipjack may beadequate for most VDE security needs.

[1628] The capability of downloading code and other informationdynamically into PPE 650 allows key length to be adjusted and changeddynamically even after a significant number of VDE electronic appliances600 are in use. The ability of a VDE administrator to communicate witheach PPE 650 efficiently makes such after-the-fact dynamic changes bothpossible and cost-effective. New or modified cryptosystems can bedownloaded into existing PPEs 650 to replace or add to the cryptosystemrepertoire available within the PPE, allowing older PPEs to maintaincompatibility with newer PPEs and/or newly released VDE objects 300 andother VDE-protected information. For example, softwareencryption/decryption algorithms may be downloaded into PPE 650 at anytime to supplement the hardware-based functionality of encrypt/decryptengine 522 by providing different key length capabilities. To provideincreased flexibility, PPE encrypt/decrypt engine 522 may be configuredto anticipate multiple passes and/or variable and/or longer key lengths.In addition, it may be desirable to provide PPEs 650 with the capabilityto internally generate longer PK keys.

[1629] C. Key Generation

[1630] Key generation techniques provided by the preferred embodimentpermit PPE 650 to generate keys and other information that are “own”only to it.

[1631] The security of encrypted information rests in the security ofthe key used to encrypt it. If a cryptographically weak process is usedto generate keys, the entire security is weak. Good keys are random bitstrings so that every possible key in the key space is equally likely.Therefore, keys should in general be derived from a reliably randomsource, for example, by a cryptographically secure pseudo-random numbergenerator seeded from such a source. Examples of such key generators aredescribed in Schneier, Applied Cryptography (John Wiley and Sons, 1994),chapter 15. If keys are generated outside a given PPE 650 (e.g., byanother PPE 650), they must be verified to ensure they come from atrusted source before they can be used. “Certification” may be used toverify keys.

[1632] The preferred embodiment PPE 650 provides for the automaticgeneration of keys. For example, the preferred embodiment PPE 650 maygenerate its own public/private key pair for use in protecting PK-basedexternal communications and for other reasons. A PPE 650 may alsogenerate its own symmetric keys for various purposes during and afterinitialization. Because a PPE 650 provides a secure environment, mostkey generation in the preferred embodiment may occur within the PPE(with the possible exception of initial PPE keys used at manufacturingor installation time to allow a PPE to authenticate initial downloadmessages to it).

[1633] Good key generation relies on randomness. The preferredembodiment PPE 650 may, as mentioned above in connection with FIG. 9,includes a hardware-based random number generator 542 with thecharacteristics required to generate reliable random numbers. Theserandom numbers may be used to “seed” a cryptographically strongpseudo-random number generator (e.g., DES operated in Output FeedbackMode) for generation of additional key values derived from the randomseed. In the preferred embodiment, random number generator 542 mayconsist of a “noise diode” or other physically-based source of randomvalues (e.g., radioactive decay).

[1634] If no random number generator 542 is available in the PPE 650,the SPE 503 may employ a cryptographic algorithm (e.g., DES in OutputFeedback Mode) to generate a sequence of pseudo-random values derivedfrom a secret value protected within the SPE. Although these numbers arepseudo-random rather than truly random, they are cryptographicallyderived from a value unknown outside the SPE 503 and therefore may besatisfactory in some applications.

[1635] In an embodiment incorporating an HPE 655 without an SPE 503, therandom value generator 565 software may derive reliably random numbersfrom unpredictable external physical events (e.g., high-resolutiontiming of disk I/O completions or of user keystrokes at an attachedkeyboard 612).

[1636] Conventional techniques for generating PK and non-PK keys basedupon such “seeds” may be used. Thus, if performance and manufacturingcosts permit, PPE 650 in the preferred embodiment will generate its ownpublic/private key pair based on such random or pseudo-random “seed”values. This key pair may then be used for external communicationsbetween the PPE 650 that generated the key pair and other PPEs that wishto communicate with it. For example, the generating PPE 650 may revealthe public key of the key pair to other PPEs. This allows other PPEs 650using the public key to encrypt messages that may be decrypted only bythe generating PPE (the generating PPE is the only PPE that “mows” thecorresponding “private key”). Similarly, the generating PPE 650 mayencrypt messages using its private key that, when decrypted successfullyby other PPEs with the generating PPE's public key, permit the otherPPEs to authenticate that the generating PPE sent the message.

[1637] Before one PPE 650 uses a public key generated by another PPE, apublic key certification process should be used to provide authenticitycertificates for the public key. A public-key certificate is someone'spublic key “signed” by a trustworthy entity such as an authentic PPE 650or a VDE administrator. Certificates are used to thwart attempts toconvince a PPE 650 that it is communicating with an authentic PPE whenit is not (e.g., it is actually communicating with a person attemptingto break the security of PPE 650). One or more VDE administrators in thepreferred embodiment may constitute a certifying authority. By “signing”both the public key generated by a PPE 650 and information about the PPEand/or the corresponding VDE electronic appliance 600 (e.g., site ID,user ID, expiration date, name, address, etc.), the VDE administratorcertifying authority can certify that information about the PPE and/orthe VDE electronic appliance is correct and that the public key belongsto that particular VDE mode.

[1638] Certificates play an important role in the trustedness of digitalsignatures, and also are important in the public-key authenticationcommunications protocol (to be discussed below). In the preferredembodiment, these certificates may include information about thetrustedness/level of security of a particular VDE electronic appliance600 (e.g., whether or not it has a hardware-based SPE 503 or is insteada less trusted software emulation type HPE 655) that can be used toavoid transmitting certain highly secure information to lesstrusted/secure VDE installations.

[1639] Certificates can also play an important role in decommissioningrogue users and/or sites. By including a site and/or user ID in acertificate, a PPE can evaluate this information as an aspect ofauthentication. For example, if a VDE administrator or clearinghouseencounters a certificate bearing an ID (or other information that meetscertain criteria (e.g., is present on a list of decommissioned and/orotherwise suspicious users and/or sites), they may choose to takeactions based on those criteria such as refusing to communicate,communicating disabling information, notifying the user of thecondition, etc. Certificates also typically include an expiration dateto ensure that certificates must be replaced periodically, for example,to ensure that sites and/or users must stay in contact with a VDEadministrator and/or to allow certification keys to be changedperiodically. More than one certificate based on different keys may beissued for sites and/or users so that if a given certification key iscompromised, one or more “backup” certificates may be used. If acertification key is compromised, A VDE administrator may refuse toauthenticate based on certificates generated with such a key, and send asignal after authenticating with a “backup” certificate that invalidatesall use of the compromised key and all certificates associated with itin further interactions with VDE participants. A new one or more“backup” certificates and keys may be created and sent to theauthenticated site/user after such a compromise.

[1640] If multiple certificates are available, some of the certificatesmay be reserved as backups. Alternatively or in addition, onecertificate from a group of certificates may be selected (e.g., by usingRNG 542) in a given authentication, thereby reducing the likelihood thata certificate associated with a compromised certification key will beused. Still alternatively, more than one certificate may be used in agiven authentication.

[1641] To guard against the possibility of compromise of thecertification algorithm (e.g., by an unpredictable advance in themathematical foundations on which the algorithm is based), distinctalgorithms may used for different certificates that are based ondifferent mathematical foundations.

[1642] Another technique that may be employed to decrease theprobability of compromise is to keep secret (in protected storage in thePPE 650) the “public” values on which the certificates are based,thereby denying an attacker access to values that may aid in the attack.Although these values are nominally “public,” they need be known only tothose components which actually validate certificates (i.e., the PPE650).

[1643] In the preferred embodiment, PPE 650 may generate its owncertificate, or the certificate may be obtained externally, such as froma certifying authority VDE administrator. Irrespective of where thedigital certificate is generated, the certificate is eventuallyregistered by the VDE administrator certificate authority so that otherVDE electronic appliances 600 may have access to (and trust) the publickey. For example, PPE 650 may communicate its public key and otherinformation to a certifying authority which may then encrypt the publickey and other information using the certifying authority's private key.Other installations 600 may trust the “certificate” because it can beauthenticated by using the certifying authority's public key to decryptit. As another example, the certifying authority may encrypt the publickey it receives from the generating PPE 650 and use it to encrypt thecertifying authority's private key. The certifying authority may thensend this encrypted information back to the generating PPE 650. Thegenerating PPE 650 may then use the certifying authority's private keyto internally create a digital certificate, after which it may destroyits copy of the certifying authority's private key. The generating PPE650 may then send out its digital certificate to be stored in acertification repository at the VDE administrator (or elsewhere) ifdesired. The certificate process can also be implemented with anexternal key pair generator and certificate generator, but might besomewhat less secure depending on the nature of the secure facility. Insuch a case, a manufacturing key should be used in PPE 650 to limitexposure to the other keys involved.

[1644] A PPE 650 may need more than one certificate. For example, acertificate may be needed to assure other users that a PPE is authentic,and to identify the PPE. Further certificates may be needed forindividual users of a PPE 650. These certificates may incorporate bothuser and site information or may only include user information.Generally, a certifying authority will require a valid site certificateto be presented prior to creating a certificate for a given user. Usersmay each require their own public key/private key pair in order toobtain certificates. VDE administrators, clearinghouses, and otherparticipants may normally require authentication of both the site (PPE650) and of the user in a communication or other interaction. Theprocesses described above for key generation and certification for PPEs650 may also be used to form site/user certificates or usercertificates.

[1645] Certificates as described above may also be used to certify theorigin of load modules 1100 and/or the authenticity of administrativeoperations. The security and assurance techniques described above may beemployed to decrease the probability of compromise for any suchcertificate (including certificates other than the certificate for a VDEelectronic appliance 600's identity).

[1646] D. Key Aging and Convolution

[1647] PPE 650 also has the ability in the preferred embodiment togenerate secret keys and other information that is shared betweenmultiple PPEs 650. In the preferred embodiment, such secret keys andother information may be shared between multiple VDE electronicappliances 600 without requiring the shared secret information to everbe communicated explicitly between the electronic appliances. Morespecifically, PPE 650 uses a technique called “key convolution” toderive keys based on a deterministic process in response to seedinformation shared between multiple VDE electronic appliances 600. Sincethe multiple electronic appliances 600 “know” what the “seed”information is and also “know” the deterministic process used togenerate keys based on this information, each of the electronicappliances may independently generate the “true key.” This permitsmultiple VDE electronic appliances 600 to share a common secret keywithout potentially compromising its security by communicating it overan insecure channel.

[1648] No encryption key should be used for an indefinite period. Thelonger a key is used, the greater the chance that it may be compromisedand the greater the potential loss if the key is compromised but stillin use to protect new information. The longer a key is used, the moreinformation it may protect and therefore the greater the potentialrewards for someone to spend the effort necessary to break it. Further,if a key is used for a long time, there may be more ciphertext availableto an attacker attempting to break the key using a ciphertext-basedattack. See Schneier at 150-151. Key convolution in the preferredembodiment provides a way to efficiently change keys stored in securedatabase 610 on a routine periodic or other basis while simplifying keymanagement issues surrounding the change of keys. In addition, keyconvolution may be used to provide “time aged keys” (discussed below) toprovide “expiration dates” for key usage and/or validity.

[1649]FIG. 62 shows an example implementation of key convolution in thepreferred embodiment. Key convolution may be performed using acombination of a site ID 2821 and the high-order bits of the RTC 528 toyield a site-unique value “V” that is time-dependent on a large scale(e.g., hours or days). This value “V” may be used as the key for anencryption process 2871 that transforms a convolution seed value 2861into a “current convolution key” 2862. The seed value 2861 may be auniverse-wide or group-wide shared secret value, and may be stored insecure key storage (e.g., protected memory within PPE 650). The seedvalue 2861 is installed during the manufacturing process and may beupdated occasionally by a VDE administrator. There may be a plurality ofseed values 2861 corresponding to different sets of objects 300.

[1650] The current convolution key 2862 represents an encoding of thesite ID 2821 and current time. This transformed value 2862 may be usedas a key for another encryption process 2872 to transform the stored key810 in the object's PERC 808 into the true private body key 2863 for theobject's contents.

[1651] The “convolution function” performed by blocks 2861, 2871 may,for example, be a one-way function that can be performed independentlyat both the content creator's site and at the content user's site. Ifthe content user does not use precisely the same convolution functionand precisely the same input values (e.g., time and/or site and/or otherinformation) as used by the content creator, then the result of theconvolution function performed by the content user will be differentfrom the content creator's result. If the result is used as asymmetrical key for encryption by the content creator, the content userwill not be able to decrypt unless the content user's result is the sameas the result of the content creator.

[1652] The time component for input to the key convolution function maybe derived from RTC 528 (care being taken to ensure that slightdifferences in RTC synchronization between VDE electronic applianceswill not cause different electronic appliances to use different timecomponents). Different portions of the RTC 528 output may be used toprovide keys with different valid durations, or some tolerance can bebuilt into the process to try several different key values. For example,a “time granularity” parameter can be adjusted to provide time tolerancein terms of days, weeks, or any other time period. As one example, ifthe “time granularity” is set to 2 days, and the tolerance is ±2 days,then three real-time input values can be tried as input to theconvolution algorithm. Each of the resulting key values may be tried todetermine which of the possible keys is actually used. In this example,the keys will have only a 4 day life span.

[1653]FIG. 63 shows how an appropriate convoluted key may be picked inorder to compensate for skew between the user's RTC 528 and theproducer's RTC 528. A sequence of convolution keys 2862(a-e) may begenerated by using different input values 2881 a-e, each derived fromthe site ID 2821 and the RTC 528 value plus or minus a differential(e.g., −2 days, −1 days, no delta, +1 days, +2 days). The convolutionsteps 2871(a-e) are used to generate the sequence of keys 2862(a-e).

[1654] Meanwhile, the creator site may use the convolution step 2871(z)based on his RTC 528 value (adjusted to correspond to the intendedvalidity time for the key) to generate a convoluted key 2862(z), whichmay then be used to generate the content key 2863 in the object's PERC808. To decrypt the object's content, the user site may use each of itssequence of convolution keys 2862(a-e) to attempt to generate the mastercontent key 810. When this is attempted, as long as the RTC 538 of thecreator site is within acceptable tolerance of the RTC 528 at the usersite, one of keys 2862(a-e) will match key 2862(z) and the decryptionwill be successful. In this example, matching is determined by validityof decrypted output, not by direct comparison of keys.

[1655] Key convolution as described above need not use both site ID andtime as a value. Some keys may be generated based on current real time,other keys might be generated on site ID, and still other keys might begenerated based on both current real-time and site ID.

[1656] Key convolution can be used to provide “time-aged” keys. Such“time-aged” keys provide an automatic mechanism for allowing keys toexpire and be replaced by “new” keys. They provide a way to give a usertime-limited rights to make time-limited use of an object, or portionsof an object, without requiring user re-registration but retainingsignificant control in the hands of the content provider oradministrator, If secure database 610 is sufficiently secure, similarcapabilities can be accomplished by checking an expiration date/timeassociated with a key, but this requires using more storage space foreach key or group of keys.

[1657] In the preferred embodiment, PERCs 808 can include an expirationdate and/or time after which access to the VDE-protected informationthey correspond to is no longer authorized. Alternatively or inaddition, after a duration of time related to some aspect of the use ofthe electronic appliance 600 or one or more VDE objects 300, a PERC 808can force a user to send audit history information to a clearinghouse,distributor, client administrator, or object creator in order to regainor retain the right to use the object(s). The PERC 808 can enforce suchtime-based restrictions by checking/enforcing parameters that limit keyusage and/or availability past time of authorized use. “Time aged” keysmay be used to enforce or enhance this tape of time-related control ofaccess to VDE protected information.

[1658] “Time aged” keys can be used to encrypt and decrypt a set ofinformation for a limited period of time, thus requiring re-registrationor the receipt of new permissions or the passing of audit information,without which new keys are not provided for user use. Time aged keys canalso be used to improve system security since one or more keys would beautomatically replaced based on the time ageing criteria—and thus,cracking secure database 610 and locating one or more keys may have noreal value. Still another advantage of using time aged keys is that theycan be generated dynamically—thereby obviating the need to storedecryption keys in secondary and/or secure memory.

[1659] A “time aged key” in the preferred embodiment is not a “true key”that can be used for encryption/decryption, but rather is a piece ofinformation that a PPE 650, in conjunction with other information, canuse to generate a “true key.” This other information can be time-based,based on the particular “ID” of the PPE 650, or both. Because the “truekey” is never exposed but is always generated within a secure PPE 650environment, and because secure PPEs are required to generate the “truekey,” VDE 100 can use “time aged” keys to significantly enhance securityand flexibility of the system.

[1660] The process of “aging” a key in the preferred embodiment involvesgenerating a time-aged “true key” that is a function of: (a) a “truekey,” and (b) some other information (e.g., real time parameters, siteID parameters, etc.) This information is combined/transformed (e.g.,using the “key convolution” techniques discussed above) to recover orprovide a “true key.” Since the “true key” can be recovered, this avoidshaving to store the “true key” within PERC 808, and allow different“true keys” to correspond to the same information within PERC 808.Because the “true key” is not stored in the PERC 808, access to the PERCdoes not provide access to the information protected by the “true key.”Thus, “time aged” keys allows content creators/providers to impose alimitation (e.g., site based and/or time based) on information accessthat is, in a sense, “external of” or auxiliary to the permissioningprovided by one or more PERCs 808. For example, a “time aged” key mayenforce an additional time limitation on access to certain protectedinformation, this additional time limitation being independent of anyinformation or permissioning contained within the PERC 808 and beinginstead based on one or more time and/or site ID values.

[1661] As one example, time-aged decryption keys may be used to allowthe purchaser of a “trial subscription” of an electronically publishednewspaper to access each edition of the paper for a period of one week,after which the decryption keys will no longer work. In this example,the user would need to purchase one or more new PERCs 808, or receive anupdate to an existing one or more permissions records, to accesseditions other than the ones from that week. Access to those othereditions which might be handled with a totally different pricingstructure (e.g., a “regular” subscription rate as opposed to a free orminimal “trial” subscription rate).

[1662] In the preferred embodiment, time-aged-based “true keys” can begenerated using a one-way or invertible “key convolution” function.Input parameters to the convolution function may include the suppliedtime-aged keys; user and/or site specific values; a specified portion(e.g., a certain number of high order bits) of the time value from anRTC 528 (if present) or a value derived from such time value in apredefined manner; and a block or record identifier that may be used toensure that each time aged key is unique. The output of the “keyconvolution” function may be a “true key” that is used for decryptionpurposes until discarded. Running the function with a time-aged key andinappropriate time values typically yields a useless key that will notdecrypt.

[1663] Generation of a new time aged key can be triggered based on somevalue of elapsed, absolute or relative time (e.g., based on a real timevalue from a clock such as RTC 528). At that time, the convolution wouldproduce the wrong key and decryption could not occur until the time-agedkey is updated. The criteria used to determine when a new “time agedkey” is to be created may itself be changed based on time or some otherinput variable to provide yet another level of security. Thus, theconvolution function and/or the event invoking it may change, shift oremploy a varying quantity as a parameter.

[1664] One example of the use of time-aged keys is as follows:

[1665] 1) A creator makes a “true” key, and encrypts content with it.

[1666] 2) A creator performs a “reverse convolution” to yield a “timeaged key” using, as input parameters to the “reverse convolution”:

[1667] a) the “true” key,

[1668] b) a time parameter (e.g., valid high-order time bits of RTC528), and

[1669] c) optional other information (e.g., site ID and/or user ID).

[1670] 3) The creator distributes the “time-aged key” to content users(the creator may also need to distribute the convolution algorithmand/or parameters if she is not using a convolution algorithm alreadyavailable to the content users' PPE 650).

[1671] 4) The content user's PPE 650 combines:

[1672] a) “time-aged” key

[1673] b) high-order time bits

[1674] c) required other information (same as 2c).

[1675] It performs a convolution function (i.e., the inverse of “reverseconvolution” algorithm in step (2) above) to obtain the “true” key. Ifthe supplied time and/or other information is “wrong,” the convolutionfunction will not yield the “true” key, and therefore content cannot bedecrypted.

[1676] Any of the key blocks associated with VDE objects 300 or otheritems can be either a regular key block or a time-aged key block, asspecified by the object creator during the object configuration process,or where appropriate, a distributor or client administrator.

[1677] “Time aged” keys can also be used as part of protocols to providesecure communications between PPEs 650. For example, instead ofproviding “true” keys to PPE 650 for communications, VDE 100 may provideonly “partial” communication keys to the PPE. These “partial” keys maybe provided to PPE 650 during initialization, for example. Apredetermined algorithm may produce “true keys” for use toencrypt/decrypt information for secure communications. The predeterminedalgorithm can “age” these keys the same way in all PPEs 650, or PPEs 650can be required to contact a VDE administrator at some predeterminedtime so a new set of partial communications keys can be downloaded tothe PPEs. If the PPE 650 does not generate or otherwise obtain “new”partial keys, then it will be disabled from communicating with otherPPEs (a fisher, “fail safe” key may be provided to ensure that the PPEcan communicate with a VDE administrator for reinitialization purposes).Two sets of partial keys can be maintained within a PPE 650 to allow afixed amount of overlap time across all VDE appliances 600. The older ofthe two sets of partial keys can be updated periodically.

[1678] The following additional types of keys (to be discussed below)can also be “aged” in the preferred embodiment.

[1679] individual message keys (i.e., keys used for a particularmessage),

[1680] administrative, stationary and traveling object shared keys,

[1681] secure database keys, and

[1682] private body and content keys.

[1683] Initial Installation Key Management

[1684]FIG. 64 shows the flow of universe-wide, or “master,” keys duringcreating of a PPE 650. In the preferred embodiment, the PPE 650 containsa secure non-volatile key storage 2802 (e.g. SPU 500 non-volatile RAM534 B or protected storage maintained by HPE 655) that is initializedwith keys generated by the manufacturer and by the PPE itself.

[1685] The manufacturer possesses (i.e., knows, and protects fromdisclosure or modification) one or more public key 2811/private key 2812key pairs used for signing and validating site identificationcertificates 2821. For each site, the manufacturer generates a site ID2821 and list of site characteristics 2822. In addition, themanufacturer possesses the public keys 2813, 2814 for validating loadmodules and initialization code downloads. To enhance security, theremay be a plurality of such certification keys, and each PPE 650 may beinitialized using only a subset of such keys of each type.

[1686] As part of the initialization process, the PPE 650 may generateinternally or the manufacturer may generate and supply, one or morepairs of site-specific public keys 2815 and private keys 2816. These areused by the PPE 650 to prove its identity. Similarly, site-specificdatabase key(s) 2817 for the site are generated, and if needed (i.e., ifa Random Number Generator 542 is not available), a random initializationseed 2818 is generated.

[1687] The initialization may begin by generating site ID 2821 andcharacteristics 2822 and the site public key 2815/private key 2816pair(s). These values are combined and may be used to generate one ormore site identity certificates 2823. The site identity certificates2823 may be generated by the public key generation process 2804, and maybe stored both in the PPE's protected key storage 2802 and in themanufacturer's VDE site certificate database 2803.

[1688] The certification process 2804 may be performed either by themanufacturer or internally to the PPE 650. If performed by the PPE 650,the PPE will temporarily receive the identity certification privatekey(s) 2812, generate the certificate 2823, store the certificate inlocal key storage 2802 and transmit it to the manufacturer, after whichthe PPE 650 must erase its copy of the identity certification privatekey(s) 2812.

[1689] Subsequently, initialization may require generation, by the PPE650 or by the manufacturer, of site-specific database key(s) 2817 and ofsite-specific seed value(s) 2818, which are stored in the key storage2802. In addition, the download certification key(s) 2814 and the loadmodule certification key(s) 2813 may be supplied by the manufacturer andstored in the key storage 2802. These may be used by the PPE 650 tovalidate all further communications with external entities.

[1690] At this point, the PPE 650 may be further initialized withexecutable code and data by downloading information certified by theload module key(s) 2813 and download key(s) 2814. In the preferredembodiment, these keys may be used to digitally sign data to be loadedinto the PPE 650, guaranteeing its validity, and additional key(s)encrypted using the site-specific public key(s) 2815 may be used toencrypt such data and protect it from disclosure.

[1691] Installation and Update Key Management

[1692]FIG. 65 illustrates an example of further key installation eitherby the manufacturer or by a subsequent update by a VDE administrator.The manufacturer or administrator may supply initial or new values forprivate header key(s) 2831, external communication key(s) 2832,administrative object keys 2833, or other shared key(s) 2834. These keysmay be universe-wide in the same sense as the global certification keys2811, 2813, and 2814, or they may be restricted to use within a definedgroup of VDE instances.

[1693] To perform this installation, the installer retrieves thedestination site's identity certificate(s) 2823, and from that extractsthe site public key(s) 2815. These key(s) may be used in an encryptionprocess 2841 to protect the keys being installed. The key(s) beinginstalled are then transmitted inside the destination site's PPE 650.Inside the PPE 650, the decryption process 2842 may use the site privatekey(s) 2816 to decrypt the transmission. The PPE 650 then stores theinstalled or updated keys in its key storage 2802.

[1694] Object-Specific Key Use

[1695]FIGS. 66 and 67 illustrate the use of keys in protecting data andcontrol information associated with VDE objects 300.

[1696]FIG. 66 shows use of a stationary content object 850 whose controlinformation is derived from an administrative object 870. The objectsmay be received by the PPE 650 (e.g. by retrieval from an objectrepository 728 over a network or retrieved from local storage). Theadministrative object decryption process 2843 may use the private headerkey(s) 2815 to decrypt the administrative object 870, thus retrievingthe PERC 808 governing access to the content object 850. The privatebody key(s) 810 may then be extracted from the PERC 808 and used by thecontent decryption process 2845 to make the content available outsidethe PPE 650. In addition, the database key(s) 2817 may be used by theencryption process 2844 to prepare the PERC for storage outside the PPE650 in the secure database 610. In subsequent access to the contentobject 850, the PERC 808 may be retrieved from the secure database 610,decrypted with database key(s) 2817, and used directly, rather thanbeing extracted from administrative object 870.

[1697]FIG. 67 shows the similar process involving a traveling object860. The principal distinction between FIGS. 66 and 67 is that the PERC808 is stored directly within the traveling object 860, and thereforemay be used immediately after the decryption process 2843 to provide aprivate header key(s) 2831 This private header key 2831 is used toprocess content within the traveling object 860.

[1698] Secret-Key Variations

[1699]FIGS. 64 through 67 illustrate the preferred public-keyembodiment, but may also be used to help understand the secret-keyversions. In secret-key embodiments, the certification process and thepublic key encryptions/decryptions are replaced with private-keyencryptions, and the public key/private-key pairs are replaced withindividual secret keys that are shared between the PPE 650 instance andthe other parties (e.g., the load module supplier(s), the PPEmanufacturer). In addition, the certificate generation process 2804 isnot performed in secret-key embodiments, and no site identitycertificates 2823 or VDE certificate database 2803 exist.

[1700] Key Types

[1701] The detailed descriptions of key types below further explainsecret-key embodiments; this summary is not intended as a completedescription. The preferred embodiment PPE 650 can use different types ofkeys and/or different “shared secrets” for different purposes. Some keytypes apply to a Public-Key/Secret Key implementation, other keys applyto a Secret Key only implementation, and still other key types apply toboth. The following table lists examples of various key and “sharedsecret” information used in the preferred embodiment, and where thisinformation is used and stored: Key/Secret Information Used in PK orType Non-PK Example Storage Location(s) Master Key(s) (may Both PPEinclude some of the Manufacturing facility specific keys mentioned VDEadministrator below Manufacturing Key Both PK PPE (PK case) optionalManufacturing facility Certification key pair PK PPE Certificationrepository Public/private key pair PK PPE Certification repository(Public Key only) Initial secret key Non-PK PPE PPE manufacturing IDNon-PK PPE Site ID, shared code, Both PPE shared keys and shared secretsDownload Both PPE authorization key VDE administrator External Both PPEcommunication keys Secure Database and other info Administrative objectBoth Permission record keys Stationary object keys Both Permissionrecord Traveling object shared Both Permission record keys Securedatabase keys Both PPE Private body keys Both Secure database Someobjects Content keys Both Secure database Some objects Authorizationshared Both Permission record secrets Secure Database Back Both PPE inkeys Secure database

[1702] Master Keys

[1703] A “master” key is a key used to encrypt other keys. An initial or“master” key may be provided within PPE 650 for communicating other keysin a secure way. During initialization of PPE 650, code and shared keysare downloaded to the PPE. Since the code contains secure convolutionalgorithms and/or coefficients, it is comparable to a “master key.” Theshared keys may also be considered “master keys.”

[1704] If public-key cryptography is used as the basis for externalcommunication with PPE 650, then a master key is required during the PPEPublic-key pair certification process. This master key may be, forexample, a private key used by the manufacturer or VDE administrator toestablish the digital certificate (encrypted public key and otherinformation of the PPE), or it may, as another example, be a private keyused by a VDE administrator to encrypt the entries in a certificationrepository. Once certification has occurred, external communicationsbetween PPEs 650 may be established using the certificates ofcommunicating PPEs.

[1705] If shared secret keys are used as the basis for externalcommunications, then an initial secret key is required to establishexternal communications for PPE 650 initialization. This initial secretkey is a “master key” in the sense that it is used to encrypt otherkeys. A set of shared partial external communications keys (seediscussion above) may be downloaded during the PPE initializationprocess, and these keys are used to establish subsequent external PPEcommunications.

[1706] Manufacturing Key

[1707] A manufacturing key is used at the time of PPE manufacture toprevent knowledge by the manufacturing staff of PPE-specific keyinformation that is downloaded into a PPE at initialization time. Forexample, a PPE 650 that operates as part of the manufacturing facilitymay generate information for download into the PPE being initialized.This information must be encrypted during communication between the PPEs650 to keep it confidential, or otherwise the manufacturing staff couldread the information. A manufacturing key is used to protect theinformation. The manufacturing key may be used to protect various otherkeys downloaded into the PPE such as, for example, a certificationprivate key, a PPE public/private key pair, and/or other keys such asshared secret keys specific to the PPE. Since the manufacturing key isused to encrypt other keys, it is a “master key.”

[1708] A manufacturing key may be public-key based, or it may be basedon a shared secret. Once the information is downloaded, thenow-initialized PPE 650 can discard (or simply not use) themanufacturing key. A manufacturing key may be hardwired into PPE 650 atmanufacturing time, or sent to the PPE as its first key and discardedafter it is no longer needed. As indicated in the table above and in thepreceding discussion, a manufacturing key is not required if PKcapabilities are included in the PPE.

[1709] Certification Key Pair

[1710] A certification key pair may be used as part of a “certification”process for PPEs 650 and VDE electronic appliances 600. Thiscertification process in the preferred embodiment may be used to permita VDE electronic appliance to present one or more “certificates”authenticating that it (or its key) can be trusted. As described above,this “certification” process may be used by one PPE 650 to “certify”that it is an authentic VDE PPE, it has a certain level of security andcapability set (e.g., it is hardware based rather than merely softwarebased), etc. Briefly, the “certification” process may involve using acertificate private key of a certification key pair to encrypt a messageincluding another VDE node's public-key. The private key of acertification key pair is preferably used to generate a PPE certificate.It is used to encrypt a public-key of the PPE. A PPE certificate caneither be stored in the PPE, or it may be stored in a certificationrepository.

[1711] Depending on the authentication technique chosen, the public keyand the private key of a certification key pair may need to beprotected. In the preferred embodiment, the certification public key(s)is distributed amongst PPEs such that they may make use of them indecrypting certificates as an aspect of authentication. Since, in thepreferred embodiment, this public key is used inside a PPE 650, there isno need for this public key to be available in plaintext, and in anyevent it is important that such key be maintained and transmitted withintegrity (e.g., during initialization and/or update by a VDEadministrator). If the certification public key is kept confidential(i.e., only available in plaintext inside the PPE 650), it may makecracking security much more difficult. The private key of acertification key pair should be kept confidential and only be stored bya certifying authority (i.e., should not be distributed).

[1712] In order to allow, in the preferred embodiment, the ability todifferentiate installations with different levels/degrees oftrustedness/security, different certification key pairs may be used(e.g., different certification keys may be used to certify SPEs 503 thenare used to certify HPEs 655).

[1713] PPE Public/Private Key Pair

[1714] In the preferred embodiment, each PPE 650 may have its own unique“device” (and/or user) public/private key pair. Preferably, the privatekey of this key pair is generated within the PPE and is never exposed inany form outside of the PPE. Thus, in one embodiment, the PPE 650 may beprovided with an internal capability for generating key pairsinternally. If the PPE generates its own public-key crypto-system keypairs internally, a manufacturing key discussed above may not be needed.If desired, however, for cost reasons a key pair may be exposed only atthe time a PPE 650 is manufactured, and may be protected at that timeusing a manufacturing key. Allowing PPE 650 to generate its public keypair internally allows the key pair to be concealed, but may in someapplications be outweighed by the cost of putting a public-key key pairgenerator into PPE 650.

[1715] Initial Secret Key

[1716] The initial secret key is used as a master key by a secret keyonly based PPE 650 to protect information downloaded into the PPE duringinitialization. It is generated by the PPE 650, and is sent from the PPEto a secure manufacturing database encrypted using a manufacturing key.The secure database sends back a unique PPE manufacturing ID encryptedusing the initial secret key in response.

[1717] The initial secret key is likely to be a much longer key thankeys used for “standard” encryption due to its special role in PPEinitialization. Since the resulting decryption overhead occurs onlyduring the initialization process, multiple passes through thedecryption hardware with selected portions of this key are tolerable.

[1718] PPE Manufacturing ID

[1719] The PPE manufacturing ID is not a “key,” but does fall within theclassic definition of a “shared secret.” It preferably uniquelyidentifies a PPE 650 and may be used by the secure database 610 todetermine the PPE's initial secret key during the PPE initializationprocess.

[1720] Site ID, Shared Code, Shared Keys and Shared Secrets

[1721] The VDE site ID along with shared code, keys and secrets arepreferably either downloaded into PPE 650 during the PPE initializationprocess, or are generated internally by a PPE as part of that process.In the preferred embodiment, most or all of this information isdownloaded.

[1722] The PPE site ID uniquely identifies the PPE 650. The site ID ispreferably unique so as to uniquely identify the PPE 650 and distinguishthat PPE from all other PPEs. The site ID in the preferred embodimentprovides a unique address that may be used for various purposes, such asfor example to provide “address privacy” functions. In some cases, thesite ID may be the public key of the PPE 650. In other cases, the PPEsite ID may be assigned during the manufacturing and/or initializationprocess. In the case of a PPE 650 that is not public-key-capable, itwould not be desirable to use the device secret key as the unique siteID because this would expose too many bits of the key—and therefore adifferent information string should be used as the site ID.

[1723] Shared code comprises those code fragments that provide at leasta portion of the control program for the PPE 650. In the preferredembodiment, a basic code fragment is installed during PPE manufacturingthat permits the PPE to bootstrap and begin the initialization process.This fragment can be replaced during the initialization process, orduring subsequent download processing, with updated control logic.

[1724] Shared keys may be downloaded into PPE 650 during theinitialization process. These keys may be used, for example, to decryptthe private headers of many object structures.

[1725] When PPE 650 is operating in a secret key only mode, theinitialization and download processes may import shared secrets into thePPE 650. These shared secrets may be used during communicationsprocesses to permit PPEs 650 to authenticate the identity of other PPEsand/or users.

[1726] Download Authorization Key

[1727] The download authorization key is received by PPE 650 during theinitialization download process. It is used to authorize further PPE 650code updates, key updates, and may also be used to protect PPE securedatabase 610 backup to allow recovery by a VDE administrator (forexample) if the PPE fails. It may be used along with the site ID, timeand convolution algorithm to derive a site ID specific key. The downloadauthorization key may also be used to encrypt the key block used toencrypt secure database 610 backups. It may also be used to form a sitespecific key that is used to enable future downloads to the PPE 650.This download authorization key is not shared among all PPEs 650 in thepreferred embodiment; it is specific to functions performed byauthorized VDE administrators.

[1728] External Communications Keys and Related Secret and PublicInformation

[1729] There are several cases where keys are required when PPEs 650communicate. The process of establishing secure communications may alsorequire the use of related public and secret information about thecommunicating electronic appliances 600. The external communication keysand other information are used to support and authenticate securecommunications. These keys comprise a public-key pair in the preferredembodiment although shared secret keys may be used alternatively or inaddition.

[1730] Administrative Object Keys

[1731] In the preferred embodiment, an administrative object shared keymay be used to decrypt the private header of an administrative object870. In the case of administrative objects, a permissions record 808 maybe present in the private header. In some cases, the permissions record808 may be distributed as (or within) an administrative object thatperforms the function of providing a right to process the content ofother administrative objects. The permissions record 808 preferablycontains the keys for the private body, and the keys for the contentthat can be accessed would be budgets referenced in that permissionsrecord 808. The administrative object shared keys may incorporate timeas a component, and may be replaced when expired.

[1732] Stationary Object Keys

[1733] A stationary object shared key may be used to decrypt a privateheader of stationary objects 850. As explained above, in some cases apermissions record 808 may be present in the private header ofstationary objects. If present, the permissions record 808 may containthe keys for the private body but will not contain the keys for thecontent. These shared keys may incorporate time as a component, and maybe replaced when expired.

[1734] Traveling Object Shared Keys

[1735] A traveling object shared key may be used to decrypt the privateheader of traveling objects 860. In the preferred embodiment, travelingobjects contain permissions record 808 in their private headers. Thepermissions record 808 preferably contains the keys for the private bodyand the keys for the content that can be accessed as permitted by thepermissions record 808. These shared keys may incorporate time as acomponent, and may be replaced when expired.

[1736] Secure Database Keys

[1737] PPE 650 preferably generates these secure database keys and neverexposes them outside of the PPE. They are site-specific in the preferredembodiment, and may be “aged” as described above. As described above,each time an updated record is written to secure database 610, a new keymay be used and kept in a key list within the PPE. Periodically (andwhen the internal list has no more room), the PPE 650 may generate a newkey to encrypt new or old records. A group of keys may be used insteadof a single key, depending on the size of the secure database 610.

[1738] Private Body Keys

[1739] Private body keys are unique to an object 300, and are notdependent on key information shared between PPEs 650. They arepreferably generated by the PPE 650 at the time the private body isencrypted, and may incorporate real-time as a component to “age” them.They are received in permissions records 808, and their usage may becontrolled by budgets.

[1740] Content Keys

[1741] Content Keys are unique to an object 300, and are not dependenton key information shared between PPEs 650 They are preferably generatedby the PPE 650 at the time the content is encrypted. They mayincorporate time as a component to “age” them. They are received inpermissions records 808, and their usage may be controlled by budgets.

[1742] Authorization Shared Secrets

[1743] Access to and use of information within a PPE 650 or within asecure database 610 may be controlled using authorization “sharedsecrets” rather than keys. Authorization shared secrets may be storedwithin the records they authorize (permissions records 808, budgetrecords, etc.). The authorization shared secret may be formulated whenthe corresponding record is created. Authorization shared secrets can begenerated by an authorizing PPE 650, and may be replaced when recordupdates occur. Authorization shared secrets have some characteristicsassociated with “capabilities” used in capabilities based operatingsystems. Access tags (described below) are an important set ofauthorization shared secrets in the preferred embodiment.

[1744] Backup Keys

[1745] As described above, the secure database 610 backup consists ofreading all secure database records and current audit “roll ups” storedin both PPE 650 and externally. Then, the backup process decrypts andre-encrypts this information using a new set of generated keys. Thesekeys, the time of the backup, and other appropriate information toidentify the backup, may be encrypted multiple times and stored with thepreviously encrypted secure database files and roll up data within thebackup files. These files may then all be encrypted using a “backup key”that is generated and stored within PPE 650. This backup key 500 may beused by the PPE to recover a backup if necessary. The backup keys mayalso be securely encrypted (e.g., using a download authentication keyand/or a VDE administrator public key) and stored within the backupitself to permit a VDE administrator to recover the backup in case ofPPE 650 failure.

[1746] Cryptographic Sealing

[1747] Sealing is used to protect the integrity of information when itmay be subjected to modifications outside the control of the PPE 650,either accidentally or as an attack on the VDE security. Two specificapplications may be the computation of check values for database recordsand the protection of data blocks that are swapped out of an SPE 500.

[1748] There are two types of sealing: keyless sealing, also known ascryptographic hashing, and keyed sealing. Both employ acryptographically strong hash function, such as MD5 or SHA. Such afunction takes an input of arbitrary size and yields a fixed-size hash,or “digest.” The digest has the property that it is infeasible tocompute two inputs that yield the same digest, and infeasible to computeone input that yields a specific digest value, where “infeasible” iswith reference to a work factor based on the size of the digest value inbits. If, for example, a 256-bit hash function is to be called strong,it must require approximately on average 10{circumflex over ( )}38(2{circumflex over ( )}128) trials before a duplicated or specifieddigest value is likely to be produced.

[1749] Keyless seals may be employed as check values in database records(e.g., in PERC 808) and similar applications. A keyless seal may becomputed based on the content of the body of the record, and the sealstored with the rest of the record. The combination of seal and recordmay be encrypted to protect it in storage. If someone modifies theencrypted record without knowing the encryption key (either in the partrepresenting the data or the part representing the seal), the decryptedcontent will be different, and the decrypted check value will not matchthe digest computed from the record's data. Even though the hashalgorithm is known, it is not feasible to modify both the record's dataand its seal to correspond because both are encrypted.

[1750] Keyed seals may be employed as protection for data stored outsidea protected environment without encryption, or as a validity proofbetween two protected environments. A keyed seal is computed similarlyto a keyless seal, except that a secret initial value is logicallyprefixed to the data being sealed. The digest value thus depends both onthe secret and the data, and it is infeasible to compute a new seal tocorrespond to modified data even though the data itself is visible to anattacker. A keyed seal may protect data in storage with a single secretvalue, or may protect data in transit between two environments thatshare a single secret value.

[1751] The choice of keys or keyless seals depends on the nature of thedata being protected and whether it is additionally protected byencryption.

[1752] Tagging

[1753] Tagging is particularly useful for supporting the secure storageof important component assembly and related information on secondarystorage memory 652. Integrated use of information “tagging” andencryption strategies allows use of inexpensive mass storage devices tosecurely store information that, in part enables, limits and/or recordsthe configuration, management and operation of a VDE node and the use ofVDE protected content.

[1754] When encrypted or otherwise secured information is delivered intoa user's secure VDE processing area (e.g., PPE 650), a portion of thisinformation can be used as a “tag” that is first decrypted or otherwiseunsecured and then compared to an expected value to confirm that theinformation represents expected information. The tag thus can be used asa portion of a process confirming the identity and correctness ofreceived, VDE protected, information.

[1755] Three classes of tags that may be included in the controlstructures of the preferred embodiment:

[1756] access tags

[1757] validation tags

[1758] correlation tags.

[1759] These tags have distinct purposes.

[1760] An access tag may be used as a “shared secret” between VDEprotected elements and entities authorized to read and/or modify thetagged element(s). The access tag may be broken into separate fields tocontrol different activities independently. If an access tag is used byan element such as a method core 1000′, administrative events thataffect such an element must include the access tag (or portion of theaccess tag) for the affected element(s) and assert that tag when anevent is submitted for processing. If access tags are maintainedsecurely (e.g., created inside a PPE 650 when the elements are created,and only released from PPE 650 in encrypted structures), and onlydistributed to authorized parties, modification of structures can becontrolled more securely. Of course, control structures (e.g., PERCs808) may further limit or qualify modifications or other actionsexpressed in administrative events.

[1761] Correlation tags are used when one element references anotherelement. For example, a creator might be required by a budget owner toobtain permission and establish a business relationship prior toreferencing their budget within the creator's PERCs. After suchrelationship was formed, the budget owner might transmit one or morecorrelation tags to the creator as one aspect of allowing the creator toproduce PERCs that reference the budget owner's budget.

[1762] Validation tag may be used to help detect record substitutionattempts on the part of a tamperer.

[1763] In some respects, these three classes of tags overlap infunction. For example, a correlation tag mismatch may prevent someclasses of modification attempts that would normally be prevented by anaccess tag mismatch before an access tag check is performed. Thepreferred embodiment may use this overlap in some cases to reduceoverhead by, for example, using access tags in a role similar tovalidation tags as described above.

[1764] In general, tagging procedures involve changing, within SPE 503,encryption key(s), securing techniques(s), and/or providing specific,stored tag(s). These procedures can be employed with secure database 610information stored on said inexpensive mass storage 652 and used withina hardware SPU 500 for authenticating, decrypting, or otherwiseanalyzing, using and making available VDE protected content andmanagement database information. Normally, changing validation tagsinvolves storing within a VDE node hardware (e.g., the PPE 650) one ormore elements of information corresponding to the tagging changes.Storage of information outside of the hardware SPA's physically secure,trusted environment is a highly cost savings means of secure storage,and the security of important stored management database information isenhanced by this tagging of information. Performing this tagging“change” frequently (for example, every time a given record isdecrypted) prevents the substitution of “incorrect” information for“correct” information, since said substitution will not carryinformation which will match the tagging information stored within thehardware SPE during subsequent retrieval of the information.

[1765] Another benefit of information tagging is the use of tags to helpenforce and/or verify information and/or control mechanisms in forcebetween two or more parties. If information is tagged by one party, andthen passed to another party or parties, a tag can be used as anexpected value associated with communications and/or transactionsbetween the two parties regarding the tagged information. For example,if a tag is associated with a data element that is passed by Party A toParty B, Party B may require Party A to prove knowledge of the correctvalue of at least a portion of a tag before information related to,and/or part of, said data element is released by Party B to Party A, orvice versa. In another example, a tag may be used by Party A to verifythat information sent by Party B is actually associated with, and/orpart of, a tagged data element, or vice versa.

[1766] Establishing s Secure, Authenticated, Communication Channel

[1767] From time to time, two parties (e.g., PPEs A and B), will need toestablish a communication channel that is known by both parties to besecure from eavesdropping, secure from tampering, and to be in usesolely by the two parties whose identifies are correctly known to eachother.

[1768] The following describes an example process for establishing sucha channel and identifies how the requirements for security andauthentication may be established and validated by the parties. Theprocess is described in the abstract, in terms of the claims and beliefeach party must establish, and is not to be taken as a specification ofany particular protocol. In particular, the individual sub-steps of eachstep are not required to be implemented using distinct operations; inpractice, the establishment and validation of related proofs is oftencombined into a single operation.

[1769] The sub-steps need not be performed in the order detailed below,except to the extent that the validity of a claim cannot be provenbefore the claim is made by the other party. The steps may involveadditional communications between the two parties than are implied bythe enumerated sub-steps, as the “transmission” of information mayitself be broken into sub-steps. Also, it is not necessary to protectthe claims or the proofs from disclosure or modification duringtransmission. Knowledge of the claims (including the specificcommunication proposals and acknowledgements thereof) is not consideredprotected information. Any modification of the proofs will cause theproofs to become invalid and will cause the process to fail.

[1770] Standard public-key or secret-key cryptographic techniques can beused to implement this process (e.g., X509, AuthenticatedDiffie-Hellman, Kerberos). The preferred embodiment uses the three-wayX509 public key protocol steps.

[1771] The following may be the first two steps in the example process:

[1772] A. (precursor step): Establish means of creating validatableclaims by A

[1773] B. (precursor step): Establish means of creating validatableclaims by B

[1774] These two steps ensure that each party has a means of makingclaims that can be validated by the other party, for instance, by usinga public key signature scheme in which both parties maintain a privatekey and make available a public key that itself is authenticated by thedigital signature of a certification authority.

[1775] The next steps may be:

[1776] A (proposal step):

[1777] 1. Determine B's identity

[1778] 2. Acquire means of validating claims made by B

[1779] 3. Create a unique identity for this specific proposedcommunication

[1780] 4. Create a communication proposal identifying the parties andthe specific communication

[1781] 5. Create validatable proof of A's identity and the origin of thecommunication proposal

[1782] 6. Deliver communication proposal and associated proof to B.

[1783] These steps establish the identity of the correspondent party Band proposes a communication. Because establishment of the communicationwill require validation of claims made by B, a means must be providedfor A to validate such claims. Because the establishment of thecommunication must be unique to a specific requirement by A forcommunication, this communication proposal and all associated trafficmust be unambiguously distinguishable from all other such traffic.Because B must validate the proposal as a legitimate proposal from A, aproof must be provided that the proposal is valid.

[1784] The next steps may be as follows:

[1785] B (acknowledgement step):

[1786] 1. Extract A's identity from the communication proposal

[1787] 2. Acquire means of validating claims made by A

[1788] 3. Validate A's claim of identity and communication proposalorigin

[1789] 4. Determine the unique identification of the communicationproposal

[1790] 5. Determine that the communication proposal does not duplicatean earlier proposal

[1791] 6. Create an acknowledgement identifying the specificcommunication proposal

[1792] 7. Create validatable proof of B's identity and the origin of theacknowledgement

[1793] 8. Deliver the acknowledgement and associated proof to A.

[1794] These steps establish that party B has received A's communicationproposal and is prepared to act on it. Because B must validate theproposal, B must first determine its origin and validate itsauthenticity. B must ensure that its response is associated with aspecific proposal, and that the proposal is not a replay. If B acceptsthe proposal, it must prove both B's own identity and that B hasreceived a specific proposal.

[1795] The next steps may be:

[1796] A (establishment step):

[1797] 1. Validate B's claim acknowledgement of A's specific proposal

[1798] 2. Extract the identity of the specific communication proposalfrom the acknowledgement

[1799] 3. Determine that the acknowledgement is associated with anoutstanding communication proposal

[1800] 4. Create unique session key to be used for the proposedcommunication

[1801] 5. Create proof of session key's creation by A

[1802] 6. Create proof of session key's association with the specificcommunication proposal

[1803] 7. Create proof of receipt of B's acknowledgement

[1804] 8. Protect the session key from disclosure in transmission

[1805] 9. Protect the session key from modification in transmission

[1806] 10. Deliver protected session key and all proofs to B.

[1807] These steps allows A to specify a session key to be associatedwith all further traffic related to A's specific communication proposal.A must create the key, prove that A created it, and prove that it isassociated with the specific proposed communication. In addition, A mustprove that the session key is generated in response to B'sacknowledgement of the proposal. The session key must be protected fromdisclosure of modification to ensure that an attacker cannot substitutea different value.

[1808] Transportability of VDE Installations Between PPEs 650

[1809] In a preferred embodiment, VDE objects 300 and other secureinformation may if appropriate, be transported from one PPE 650 toanother securely using the various keys outlined above. VDE 100 usesredistribution of VDE administrative information to exchange ownershipof VDE object 300, and to allow the portability of objects betweenelectronic appliances 600.

[1810] The permissions record 808 of VDE objects 300 contains rightsinformation that may be used to determine whether an object can beredistributed in whole, in part, or at all. If a VDE object 300 can beredistributed, then electronic appliance 600 normally must have a“budget” and/or other permissioning that allows it to redistribute theobject. For example, an electronic appliance 600 authorized toredistribute an object may create an administrative object containing abudget or rights less than or equal to the budget or rights that itowns. Some administrative objects may be sent to other PPEs 650. A PPE650 that receives one of the administrative objects may have the abilityto use at least a portion of the budgets, or rights, to related objects.

[1811] Transfer of ownership of a VDE object 300 is a special case inwhich all of the permissions and/or budgets for a VDE object areredistributed to a different PPE 650. Some VDE objects may require thatall object-related information be delivered (e.g., it's possible to“sell” all rights to the object). However, some VDE objects 300 mayprohibit such a transfer. In the case of ownership transfer, theoriginal providers for a VDE object 300 may need to be contacted by thenew owner, informed of the transfer, and validated using anauthorization shared secret that accompanies reauthorization, beforetransfer of ownership can be completed.

[1812] When an electronic appliance 600 receives a component assembly,an encrypted part of the assembly may contain a value that is known onlyto the party or PPE 650 that supplied the assembly. This value may besaved with information that must eventually returned to the assemblysupplier (e.g., audit, billing and related information). When acomponent supplier requests that information be reported, the value maybe provided by the supplier so that the local electronic appliance 600can check it against the originally supplied value to ensure that therequest is legitimate. When a new component is received, the value maybe checked against an old component to determine whether the newcomponent is legitimate (e.g., the new value for use in the next reportprocess may be included with the new component).

[1813] Integrity of VDE Security

[1814] There are many ways in which a PPE 650 might be compromised. Thegoal of the security provided by VDE 100 is to reduce the possibilitythat the system will be compromised, and minimize the adverse effects ifit is compromised.

[1815] The basic cryptographic algorithm that are used to implement VDE100 are assumed to be safe (cryptographically strong). These include thesecret-key encryption of content, public-key signatures for integrityverification, public-key encryption for privacy between PPEs 650 orbetween a PPE and a VDE administrator, etc. Direct attack on thesealgorithms is assumed to be beyond the capabilities of an attacker. Fordomestic versions of VDE 100 some of this is probably a safe assumptionsince the basic building blocks for control information havesufficiently long keys and are sufficiently proven.

[1816] The following risks of threat or attacks may be significant:

[1817] Unauthorized creation or modification of component assemblies(e.g., budgets)

[1818] Unauthorized bulk disclosure of content

[1819] Compromise of one or more keys

[1820] Software emulation of a hardware PPE

[1821] Substitution of older records in place of newer records

[1822] Introduction of “rogue” (i.e., unauthentic) load modules

[1823] Replay attacks

[1824] Defeating “fingerprinting”

[1825] Unauthorized disclosure of individual content items

[1826] Redistribution of individual content items.

[1827] A significant potential security breach would occur if one ormore encryption keys are compromised. As discussed above, however, theencryption keys used by VDE 100 are sufficiently varied andcompartmentalized so that compromising one key would have only limitedvalue to an attacker in most cases. For example, if a certificationprivate key is exposed, an attacker could pass the challenge/responseprotocol as discussed above but would then confront the next level ofsecurity that would entail cracking either the initializationchallenge/response or the external communication keys. If theinitialization challenge/response security is also defeated, theinitialization code and various initialization keys would also beexposed. However, it would still be necessary to understand the code anddata to find the shared VDE keys and to duplicate the key-generation(“convolution”) algorithms. In addition, correct real time clock valuesmust be maintained by the spoof. If the attacker is able to accomplishall of this successfully, then all secure communications to the bogusPPE would be compromised. An object would be compromised ifcommunications related to the permissions record 808 of that object aresent to the bogus PPE.

[1828] Knowledge of the PPE download authorization key and thealgorithms that are used to derive the key that encrypts the keys forbackup of secured database 610 would compromise the entire secureddatabase at a specific electronic appliance 600. However, in order touse this information to compromise content of VDE objects 300, anunderstanding of appropriate VDE internals would also be required. In apreferred embodiment, the private body keys and content keys stored in asecured database 610 are “aged” by including a time component. Time isconvoluted with the stored values to derive the “true keys” needed todecrypt content. If this process is also compromised, then objectcontent or methods would be revealed. Since a backup of secured database610 is not ever restored to a PPE 650 in the preferred embodimentwithout the intervention of an authorized VDE administrator, a “bogus”PPE would have to be used to make use of this information.

[1829] External communication shared keys are used in the preferredembodiment in conjunction with a key convolution algorithm based on siteID and time. If compromised, all of the steps necessary to allowcommunications with PPEs 650 must also be known to take advantage ofthis knowledge. In addition, at least one of the administrative objectshared keys must be compromised to gain access to a decryptedpermissions record 808.

[1830] Compromising an administrative object shared key has no valueunless the “cracker” also has knowledge of external communication keys.All administrative objects are encrypted by unique keys exchanged usingthe shared external communications keys, site ID and time. Knowledge ofPPE 650 internal details would be necessary to farther decrypt thecontent of administrative objects.

[1831] The private header of a stationary object (or any otherstationary object that uses the same shared key) if compromised, mayprovide the attacker with access to content until the shared key “ages”enough to no longer decrypt the private header. Neither the private bodynor the content of the object is exposed unless a permissions record 808for that object is also compromised. The private headers of theseobjects may remain compromised until the key “ages” enough to no longerdecrypt the private header.

[1832] Secure database encryption keys in the preferred embodiment arefrequently changing and are also site specific. The consequences ofcompromising a secured database 610 file or a record depends on theinformation that has been compromised. For example, permissions record808 contain keys for the public body and content of a VDE object 300. Ifa permissions record 808 is compromised, the aspects of that objectprotected by the keys provided by the permissions record are alsocompromised—if the algorithm that generates the “true keys” is alsoknown. If a private body key becomes known, the private body of theobject is compromised until the key “ages” and expires. If the “aging”process for that key is also compromised, the breach is permanent. Sincethe private body may contain methods that are shared by a number ofdifferent objects, these methods may also become compromised. When thebreach is detected, all administrative objects that provide budgets andpermissions record should update the compromised methods. Methods storedin secure database 610 are only replaced by more recent versions, so thecompromised version becomes unusable after the update is completed.

[1833] If a content key becomes compromised, the portion of the contentencrypted with the key is also compromised until the key “ages” andexpires. If the “aging” process for that key also becomes compromised,then the breach becomes permanent. If multiple levels of encryption areused, or portions of the content are encrypted with different keys,learning a single key would be insufficient to release some or all ofthe content.

[1834] If an authorization shared secret (e.g., an access tag) becomesknown, the record containing the secret may be modified by an authorizedmeans if the “cracker” knows how to properly use the secret. Generallyspeaking, the external communications keys, the administrative objectkeys and the management file keys must also be “cracked” before a sharedsecret is useful. Of course, any detailed knowledge of the protocolswould also be required to make use of this information.

[1835] In the preferred embodiment, PPE 650 may detect whether or not ithas become compromised. For example, by comparing information stored inan SPE 503 (e.g., summary service information) with information storedin secure database 610 and/or transmitted to a VDE participant (e.g., aVDE clearinghouse), discrepancies may become evident. If PPE 650 (or aVDE administrator watching its activities or communicating with it)detects that it has been compromised, it may be updated with aninitialization to use new code, keys and new encryption/decryptionalgorithms. This would limit exposure to VDE objects 300 that existed atthe time the encryption scheme was broken. It is possible to require thePPE 650 to cease functioning after a certain period of time unless newcode and key downloads occur. It is also possible to have VDEadministrators force updates to occur. It is also likely that the desireto acquire a new VDE object 300 will provide an incentive for users toupdate their PPEs 650 at regular time intervals.

[1836] Finally, the end-to-end nature of VDE applications, in whichcontent 108 flows in one direction, generating reports and bills 118 inthe other, makes it possible to perform “back-end” consistency checks.Such checks, performed in clearinghouses 116, can detect patterns of usethat may or do indicate fraud (e.g., excessive acquisition of protectedcontent without any corresponding payment, usage records withoutcorresponding billing records). The fine grain of usage reporting andthe ready availability of usage records and reports in electronic formenables sophisticated fraud detection mechanisms to be built so thatfraud-related costs can be kept to an acceptable level.

[1837] Integrity of Software-Based PPE Security

[1838] As discussed above in cofnnection with FIG. 10, some applicationsmay use a software-based protected processing environment 650 (such as a“host event processing environment” (HPE) 655) providing asoftware-based tamper resistant barrier 674. Software-based tamperresistant barrier 674 may be created by software executing on ageneral-purpose CPU. Various software protection techniques may be usedto construct and/or provide software-based tamper resistant barrier 674.

[1839] The risks or threat of attacks described above in connection withPPE 650 apply to a software-based PPE. An important threat to becountered with respect to a software-based tamper resistant barrier 674is an attack based on a distributable computer program that can defeatthe tamper resistant barrier wherever the program is run. Since asoftware-based tamper resistant barrier 674 typically will not be assecure as a hardware-based tamper resistant barrier 502, it is useful toexplore example steps and procedures a “cracker” might use to “‘crack’ asoftware”-based tamper resistant barrier.

[1840]FIGS. 67A and 67B show example “cracking” techniques a “cracker”might use to attack software-based tamper resistant barrier 674.

[1841] Referring to FIG. 67A, the software used to create tamperresistant barrier 674 may be distributed, for example, on a storagemedium 3370 such as a floppy diskette or optical disk (or, this softwarecould be distributed electronically over network 108 and stored locallyin a computer memory). The software distribution medium 3370 providessoftware (code and data) for loading into a computing device such as ageneral purpose personal computer 3372, for example. Personal computer3372 may include, for example, a random access memory 3374 and a harddisk 3376.

[1842] In one example, the software distribution medium 3370 mightinclude installation materials 3470 and operational materials 3472. Theinstallation materials 3470 may be executed by computer 3372 to installthe operational materials 3472 onto the computer's hard disk 3376. Thecomputer 3372 may then execute the operational materials 3472 from itshard disk 3376 to provide software-based protected processingenvironment 650 and associated software-based tamper resistant barrier672.

[1843] In this example, one attack technique an attacker might use is toanalyze software distribution medium 3370 (see FIG. 67B, block 3352).Such analysis can take many forms.

[1844] Such analysis could be performed by a combination of one or moretechniques. Such techniques include, but are not limited to, thefollowing:

[1845] An attacker can manually “dump” and/or disassemble listings ofthe data from medium 3370. This analysis is represented in FIG. 67A bymagnifying glass 3352A.

[1846] An attacker can use cryptoanalytic and/or key search techniquesto decrypt any encrypted data from medium 3370.

[1847] An attacker can use automated or semi-automated disassembly toolsto explore the functions of programs stored on medium 3370 by studyingthe operation and flow of the assembly language representation of theprograms. This analysis is represented in FIG. 67A by block 3352B.

[1848] An attacker can use software reverse-engineering tools toreconstruct high-level language representations of the programs onmedium 3370, and study their functions. This analysis is represented inFIG. 67A by block 3352C, producing source code 3371.

[1849] An attacker can use software reverse-engineering tools to createan equivalent program to the programs stored on medium 3370. As theequivalent program may be in a more convenient form, possibly in ahigher-level language, it may be more amenable to analysis. Thisanalysis is also represented in FIG. 67A by block 3352C, producingsource code 3371.

[1850] An attacker can use software debugging and/or simulation tools tofollow and/or modify the dynamic execution of programs from medium 3370.This technique can be combined with any of the above static analysistechniques to study the program as it operates. This analysis isrepresented in FIG. 67A by block 3352B.

[1851] An attacker can use hardware-based debugging and/or simulationtools (e.g., an in-circuit emulator, or ICE) to follow and/or modify thedynamic execution of programs from medium 3370. This technique may bemore effective than the equivalent using software debugging and/orsimulation tools because it has less potential effect on operation ofthe programs. This analysis is represented in FIG. 67A by block 3352B.

[1852] Such analysis could provide clues and insights into theinstallation materials 3470, the operational materials 3472, or both.

[1853] Another attack technique could focus on the operational materials3472 in the form in which they are installed on personal computer 3372.For example, one form of analysis might involve analyzing the on-diskcopy of the installed software and/or associated data files installed oncomputer hard disk 3376 (see FIG. 67B, block 3354). This analysis isrepresented in FIG. 67A as a magnifying glass 3354B. Because theinstalled operational materials 3472 can be executed by computer 3372,the analysis need not be limited to analyzing the static informationstored on hard disk 3376, but could involve performing static and/ordynamic analysis of the executing software (see FIG. 67B, blocks 3356,3358). Any of the techniques described above could be used to analyzethe operational material software 3472 to yield source code or othermore interpretable form 3373A and/or a memory image 3373B. The staticand/or dynamic data within RAM 3374A could be similarly analyzed (seeFIG. 67A, magnifying glass 3354A).

[1854] The resulting source code 3373A and/or memory image 3373B couldbe carefully analyzed and reviewed (see magnifying glasses 3354D, 3354E)to obtain an understanding of both the static and dynamic structure andoperation of operational materials 3272. Dynamic code analysis couldinvolve, for example, tracing, single-stepping, data, or code breakpoints of the executing software image, using analysis techniques suchas described above. The executing software could be modified dynamically(for example, by patching) during normal operation to attempt to bypassits protection mechanisms and/or to learn more about how it operates(see FIG. 67B, block 3360, and the “changes” inserted into FIG. 67Amemory image 3373B).

[1855] A further attack technique in this example might involvecomparing installed operational material 3472 software and data filesamong several different PPE 650 instances to identify important datastructures, such as cryptographic keys (see “compare” block 3362A ofFIG. 67A; and FIG. 67B, block 3362). The resulting list of differences3362B could be carefully analyzed (see FIG. 67A's magnifying glass3362C) to obtain important clues, using analysis techniques such asdescribed above.

[1856] A further attack technique might involve comparing the memoryand/or disk images of installed operational material 3472 software anddata files in a single instance of PPE 650, after performing variousoperations using the PPE. This could serve to identify important datastructures, such as cryptographic keys (see “compare” block 3362A ofFIG. 67A; and FIG. 67B, block 3362). The resulting list of differences3362B could be carefully analyzed (see FIG. 67A's magnifying glass3362C) to obtain important clues, using analysis techniques such asdescribed above.

[1857] A further attack technique might involve analyzing the timingand/or order of modification to memory and/or disk images of installedoperational material 3472 software and data files in a single instanceof PPE 650, during the performance performing various operations usingthe PPE. This could serve to identify important data structures, such ascryptographic keys (see “compare” block 3362A of FIG. 67A; and FIG. 67B,block 3362). The resulting list of differences 3362B could be carefullyanalyzed (see FIG. 67A's magnifying glass 3362C) to obtain importantclues, using analysis techniques such as described above.

[1858] A further attack technique might involve duplicating oneinstalled operational material 3472 instance by copying the programs anddata from one personal computer 3372B to another personal computer 3372Cor emulator (see FIG. 67B, block 3364, and the “copy” arrow 3364A inFIG. 67A). The duplicated PPE instance could be used in a variety ofways, such as, for example, to place an impostor PPE 650 instanceon-line and/or to permit further dynamic analysis.

[1859] A still additional avenue of attack might involve, for example,saving the state of a PPE 650 (see FIG. 67A, block 3366B)—for example,before the expenditure of credit—and restoring the state at a subsequenttime (e.g., after a payment operation occurs) (see FIG. 67A, arrows3366A, 3366C, and FIG. 67B, block 3366). The stored state information3366B may also be analyzed (see FIG. 67A, magnifying glass 3354F.

[1860] No software-only tamper resistant barrier 674 can be whollyeffective against all of these threats. A sufficiently powerful dynamicanalysis (such as one employing an in-circuit emulator) can lay bare allof th e software-based PPE 650's secrets. Nonetheless, varioustechniques described below in connection with FIG. 69A and followingmake such an analysis extremely frustrating and timeconsuming—increasing the “work factor” to a point where it may becomecommercially unfeasible to attempt to “crack” a software-based tamperresistant barrier 674.

[1861] PPE Initialization

[1862] Each PPE 650 needs to be initialized before it can be used.Initialization may occur at the manufacturer site, after the PPE 650 hasbeen placed out in the field, or both. The manufacturing process for PPE650 typically involves embedding within the PPE sufficient software thatwill allow the device to be more completely initialized at a later time.This manufacturing process may include, for example, testing thebootstrap loader and challenge-response software permanently storedwithin PPE 650, and loading the PPE's unique ID. These steps provide abasic VDE-capable PPE 650 that may be further initialized (e.g., afterit has been installed within an electronic appliance 600 and placed inthe field). In some cases, the manufacturing and further initializationprocesses may be combined to produce “VDE ready” PPEs 650. Thisdescription elaborates on the summary presented above with respect toFIGS. 64 and 65

[1863]FIG. 68 shows an example of steps that may be performed inaccordance with one preferred embodiment to initialize a PPE 650. Someof the steps shown in this flowchart may be performed at themanufacturing site, and some may be performed remotely through contactbetween a VDE administrator and the PPE 650. Alternatively, all of thesteps shown in the diagram may be performed at the manufacturing site,or all of the steps shown may be performed through remote communicationsbetween the PPE 500 and a VDE administrator.

[1864] If the initialization process 1370 is being performed at themanufacturer, PPE 650 may first be attached to a testbed. Themanufacturing testbed may first reset the PPE 650 (e.g., with a power onclear) (Block 1372). If this reset is being performed at themanufacturer, then the PPE 650 preferably executes a special testbedbootstrap code that completely tests the PPE operation from a softwarestandpoint and fails if something is wrong with the PPE. A securecommunications exchange may then be established between themanufacturing testbed and the PPE 650 using an initialchallenge-response interaction (Block 1374) that is preferably providedas part of the testbed bootstrap process. Once this securecommunications has been established, the PPE 650 may report the resultsof the bootstrap tests it has performed to the manufacturing testbed.Assuming the PPE 650 has tested successfully, the manufacturing testbedmay download new code into the PPE 650 to update its internal bootstrapcode (Block 1376) so that it does not go through the testbed bootstrapprocess upon subsequent resets (Block 1376). The manufacturing testbedmay then load new firmware into the PPE internal non-volatile memory inorder to provide additional standard and/or customized capabilities(Block 1378). For example, the manufacturing testbed may preload PPE 650with the load modules appropriate for the particular manufacturing lot.This step permits the PPE 500 to be customized at the factory forspecific applications.

[1865] The manufacturing testbed may next load a unique device ID intoPPE 650 (Block 1380). PPE 650 now carries a unique ID that can be usedfor further interactions.

[1866] Blocks 1372-1380R typically are, in the preferred embodiment,performed at the manufacturing site. Blocks 1374 and 1382-1388 may beperformed either at the manufacturing site, after the PPE 650 has beendeployed, or both.

[1867] To further initialize PPE 650, once a secure communications hasbeen established between the PPE and the manufacturing testbed or a VDEadministrator (Block 1374), any required keys, tags or certificates areloaded into PPE 650 (Block 1382). For example, the manufacturing testbed may load its information into PPE 650 so the PPE may be initializedat a later time. Some of these values may be generated internally withinPPE 650. The manufacturing testbed or VDE administrator may theninitialize the PPE real time clock 528 to the current real time value(Block 1384). This provides a time and date reference for the PPE 650.The manufacturing testbed or the VDE administrator may next initializethe summary values maintained internally to the PPE 500 (Block 1386). Ifthe PPE 650 is already installed as part of an electronic appliance 600,the PPE may at this point initialize its secure database 610 (Block1388).

[1868]FIG. 69 shows an example of program control steps performed by PPE650 as part of a firmware download process (See FIG. 68, Block 1378).The PPE download process is used to load externally provided firmwareand/or data elements into the PPE. Firmware loads may take two forms:permanent loads for software that remains resident in the PPE 650; andtransient loads for software that is being loaded for execution. Arelated process for storing into the secure database 610 is performedfor elements that have been sent to a VDE electronic appliance 600.

[1869] PPE 650 automatically performs several checks to ensure thatfirmware being downloaded into the PPE has not been tampered with,replaced, or substituted before it was loaded. The download routine 1390shown in the figure illustrates an example of such checks. Once the PPE650 has received a new firmware item (Block 1392), it may check the itemto ensure that it decrypts properly using the predetermined download oradministrative object key (depending on the source of the element)(decision Block 1394). If the firmware decrypts properly (“yes” exits todecision Block 1394), the firmware as check valve may be calculated andcompared against the check valve stored under the encryption wrapper ofthe firmware (decision Block 1396). If the two check summed valuescompare favorably (“yes” exit to decision Block 1396), then the PPE 650may compare the public and private header identification tags associatedwith the firmware to ensure that the proper firmware was provided andhad not been substituted (step not shown in the figure). Assuming thistest also passes, the PPE 500 may calculate the digital signatures ofthe firmware (assuming digital signatures are supported by the PPE 650and the firmware is “signed”) and may check the calculated signature toensure that it compares favorably to the digital signatures under thefirmware encryption wrapper (Blocks 1398, 1400). If any of these testsfail, then the download will be aborted (“fail” termination 1401).

[1870] Assuming all of the tests described above pass, then PPE 650determines whether the firmware is to be stored within the PPE (e.g., aninternal non-volatile memory), or whether it is to be stored in thesecure database 610 (decision Block 1402). If the firmware is to bestored within the PPE (“yes” exit to decision Block 1402), then the PPE500 may simply store the information internally (Block 1404). If thefirmware is to be stored within the secure database 610 (“no” exit todecision Block 1402), then the firmware may be tagged with a uniquePPE-specific tag designed to prevent record substitution (Block 1406),and the firmware may then be encrypted using the appropriate securedatabase key and released to the secure database 610 (Block 1408).

[1871] Example Techniques for Forming Software-Based Tamper ResistantBarrier

[1872] Various software protection techniques detailed above inconnection with FIG. 10 may provide software-based tamper resistantbarrier 674 within a software-only and/or hybrid software/hardwareprotected processing environment 650. The following is an elaboration onthose above-described techniques These software protection techniquesmay provide, for example, the following:

[1873] An on-line registration process that results in the creation of ashared secret between the registry and the PPE 650 instance—used by theregistry to create content and transactions that are meaningful only tothat specific PPE instance.

[1874] An installation program (that may be distinct from the PPEoperational material software) that creates a customized installation ofthe PPE software unique to each PPE instance and/or associatedelectronic appliance 600.

[1875] Camouflage protections that make it difficult to reverse engineerthe PPE 650 operational materials during PPE operation.

[1876] Integrity checks performed during PPE 650 operation (e.g., duringon-line interactions with trusted servers) to detect compromise andminimize damage associated with any compromise.

[1877] In general, the software-based tamper resistant barrier 674 mayestablish “trust” primarily through uniqueness and complexity. Inparticular, uniqueness and customization complicate the ability of anattacker to:

[1878] make multiple PPE instances with the same apparent identity;

[1879] make it harder for an attacker to create a software program(s)that will defeat the tamper-resistant barrier 674 of multiple PPEinstances;

[1880] make it harder for the attacker to reverse engineer (e.g., basedupon encryption so that normal debugging/emulation and other softwaretesting tools can't easily provide access); and

[1881] make it more difficult for an attacker to compare multiple PPEinstances to determine differences between them.

[1882] In addition, the overall software-based tamper resistant barrier674 and associated PPE system is sufficiently complex so that it isdifficult to tamper with a part of it without destroying other aspectsof its functionality (i.e., a “defense in depth”). Camouflagingtechniques complicate an attacker's analysis through use ofdebugging/emulation or other software tools. For example, the PPE 650may rewrite or overwrite memory locations immediately after using sameto make their contents unavailable for scrutiny. Similarly, the PPE 650operational software may use hardware and/or time dependent sequences toprevent emulation. Additionally, some of the PPE 650 environment codemay be self-modifying. These and other techniques make it much harder tocrack an individual PPE 650 instance, and more importantly—much harderto write a program that could be used to defeat security on multiple PPEinstances. Because the legitimate owner/user of a particular PPEinstance may be trying to attack the security of his own system, thesetechniques assume that individual instances may eventually be crackedand provide additional security and safeguards that prevent (or make itmore difficult) for the attacker who has cracked one PPE instance to usethat information successfully in cracking other PPE instances.Specifically, these security techniques make it unlikely that anattacker who has successfully cracked one or a small number of PPEinstances can write a program capable of compromising the security ofany arbitrary other PPE instance, for example.

[1883] Example Installation Process

[1884] Briefly, the preferred example software-based PPE 650installation process provides the following security techniques:

[1885] encrypted software distribution,

[1886] installation customized on a unique instance and/or electronicappliance basis,

[1887] encrypted on-disk form,

[1888] installation tied to payment method,

[1889] unique software and data layout, and

[1890] identifiable copies.

[1891]FIG. 69A shows one example technique for distributing the PPE 650software. In this example, the PPE 650 software is distributed as twoseparate parts and/or media: the installation materials 3470, and theoperational materials 3472. Installation materials 3470 may provideexecutable code and associated data structures for installing theoperational materials 3472 onto a personal computer hard disk 3376, forexample (see FIG. 67A). The operational materials 3472 may provideexecutable code and associated data structures for providing protectedprocessing environment 650 and associated software-based tamperresistant barrier 674.

[1892] In this example, installation materials 3470 and operationalmaterials 3472 are each encrypted by a “deliverable preparation” process3474 to provide encrypted installation materials 3470E and encryptedoperational materials 3472E (the encrypted portions are indicated inFIG. 69A, by cross-hatching). In this example, a small portion 3470C ofthe installation materials 3470 may be maintained in clear (unencrypted)form to provide an initial portion of the installation routine that maybe executed without decryption. This plain text portion 3470C may, forexample, provide an initial dialog, using an encrypted or other secureprotocol with a trusted registry 3476 such as VDE administrator 200 hfor example. This makes the distributed installation materials 3470 andoperational materials 3472 meaningless and unreadable to an attackerwithout additional information since the entire content (except for theinitial dialog with the registry 3476) is unreadable.

[1893] In this example, the “deliverable preparation” process 3474 mayencrypt the installation materials 3470 and operational materials 3472using one or more secret keys known to the registry 3476. Multipleversions of these installation materials 3470 and operational materials3472 may be distributed using different, secret keys so that compromiseof one key exposes only a subset of the software distribution tounwanted disclosure. The only non-encrypted part of the softwaredistribution in plaintext is that portion 3470C of installationmaterials 3470 used to establish initial contact with the registry 3476.

[1894] The registry 3476 maintains a copy of the correspondingdecryption keys within a key generation and cataloging structure 3478.It provides these keys on demand during the registration process (e.g.,using a secure key exchange protocol, for example to only legitimateusers authorized to set up a new protected processing environment 650.

[1895] FIGS. 69B-69C show example steps that may be performed by ainstallation routine 3470 to install a protected processing environment650. In this example, upon coupling the installation materials 3470 toan electronic appliance 600 such as a personal computer 3372, theappliance begins executing the unencrypted installation materialsportion 3470C. This plain text portion 3470C controls appliance 600 tocontact registry 3476 and establish a registry dialog (FIG. 69B, block3470(1)). The appliance 600 and the registry 3476 use a secure keyexchange protocol to exchange installation keys so that the registry maydeliver the appropriate installation key to the appliance (FIG. 69B,block 3470(2)). Using the provided installation key(s), the appliance600 may decrypt and run additional portions of encrypted installationmaterials 3470E (FIG. 69B, block 3470(3) and following). Based on thisadditional installation program execution, appliance 600 may decrypt andinstall encrypted operational materials 3472E (FIG. 69B, block 3470(4)).

[1896] Rather than simply installing the operational materials 3472, inone example, installation materials 3470 makes the installationdifferent for each PPE 650 instance. For example, the installationmaterials 3470 may customize the installation by:

[1897] uniquely embedding important data into the installed software,

[1898] uniquely encrypting the installed software,

[1899] uniquely making random changes to the installed software,

[1900] uniquely mating the installed software with a particularelectronic appliance 600,

[1901] providing a unique static and/or dynamic layout or otherstructure.

[1902] Randomly Embedded Cryptographic Keys

[1903] Installation routine 3470 may, for example, modify theoperational materials 3472 to customize embedded locations wherecritical data such as cryptographic keys are stored. These keys may beembedded into the text of the operational materials 3472 at locationsthat vary with each installation. In this example, the registry 3476 maychoose, on a random or pseudo-random basis, at least some of theoperational material 3472 locations in which a particular installationroutine 3470 may embed cryptographic keys or other critical data (seeFIG. 69B, block 3470(5)).

[1904] The installation process for the operational software may involvedecrypting its distribution (which may be the same for all end users)and modifying it to encode the specific locations where its criticaldata (e.g., cryptographic keys) are stored. These keys may be embeddedwithin the text of the program at locations that vary with everyinstallation. The distribution of unique information into theoperational software 3472 can be based on a secret key known to theregistry 3476. This key may be communicated by the registry 3476 duringthe registration dialog using a secure key exchange. The key is sharedbetween the registry 3476 and the PPE 650 instance, and can serve bothto organize the installed PPE software, and as the basis of subsequentintegrity checks.

[1905] As shown in FIG. 69D, the operational materials 3472 may includeembedded locations 3480(a), 3480(b), 3480(c), 3480(d), 3480(e), . . .reserved for storing (embedding) critical information such ascryptographic keys. Each of these locations 3480 may initially store arandom number string. In one example, the registry 3476 or installationroutine 3470 performs a random operation 3482 to randomly select whichsubset of these locations 3480 is to be used by a particular instancefor storing critical data. This selection list 3484 is applied as aninput to an operation materials preparation step 3474 a (part of thedeliverable preparation operation 3474 shown in FIG. 69A). The operationmaterials preparation step 3474 a also accepts, as an input,cryptographic keys from a secure key store 3486. In this example, theoperation materials preparation step 3474 a embeds the cryptographickeys provided by key store 3486 into the selected locations 3484 ofoperation materials 3472.

[1906] In accordance with one example, the random operation 3482 selectsa subset that is much less than all of the possible locations 3480—andthe locations 3480 not used for storing cryptographic keys store randomdata instead. An attacker attempting to analyze installed operationalmaterials 3472 won't be able to tell the difference between realcryptographic keys and random number strings inserted into a place wherecryptographic keys might be stored.

[1907] In this example, the random location selection 3484 (which isunique for each installation) may itself be encrypted by block 3488based on an installation-unique key provided by key generation block3490 for example. The encryption key may be securely maintained atregistry 3476 so that the registry may later notify the installationmaterials 3470 of this key—allowing the installation materials todecrypt the resulting encrypted key location block 3492 and recoverlisting 3484 of the subset of locations 3480 used for embeddingcryptographic keys.

[1908] Embedded Customized Random Changes

[1909] Referring once again to FIG. 69B, the installed operationalmaterials 3472 may be further customized for each instance by makingrandom changes to reserved, unused portions of the operational materials(FIG. 69B, block 3470(6)). An example of this is shown in FIG. 69E. Inthis example, the operational materials 3472 include unused, embeddedrandom data or code portions 3494. Another technique with similar effectis shown in FIG. 69F. In this example, false code sections 3496 areincluded within reserved areas of the operational materials 3472. Thesefalse code sections 3496 add complexity, and may also be used as aelectronic “fingerprint” to help trace copies. Because the false codesections 3496 are executable program code that are never executed (or ifexecuted perform no actual functions other than confounding analysis by,for example, creating, modifying and/or destroying data that has noimpacton the operation of PPE 650 but may appear to have such animpact), they can be used to confound analysis because they may bedifficult for an attacker to distinguish from true code sections. Inaddition other false code may have the effect of disabling the executionof PPE 650 if executed. Correspondence Between Installed Software andAppliance “Signature”. Another technique that may be used during theinstallation routine 3470 is to customize the operational materials 3472by embedding a “machine signature” into the operational materials toestablish a correspondence between the installed software on aparticular electronic appliance 600 (FIG. 69C, block 3470(7)). Thistechnique prevents a software-based PPE 650 from being transferred fromone electronic appliance 600 to another (except through the use of theappropriate secure, verified backup mechanism).

[1910] For electronic appliances 600 where it is feasible to do so, theinstallation procedure 3470 may determine unique information about theelectronic appliance 600 (e.g., a “signature” SIG in the sense of aunique value—not necessarily a “digital signature” in the cryptographicsense). Installation routine 3470 embeds the electronic appliance“signature” SIG in the installed operational materials 3472. Uponinitialization, the operational materials 3472 validate the embeddedsignature value against the actual electronic appliance 600 signatureSIG, and may refuse to start if the comparison fails. Depending on theconfiguration of electronic appliance 600, the machine signature mayconsist, for example, of some combination of

[1911] a hash of the ROM BIOS 658′ (see FIG. 69G),

[1912] a hash of a disk defect map 3497 a,

[1913] the Ethernet (or other) network adapter 666 address,

[1914] information written into an unused disk sector,

[1915] information stored in a non-volatile CMOS RAM(such as used forhardware configuration data),

[1916] information stored in non-volatile (“flash”) memory (such as usedfor system or peripheral component “BIOS” programs) and/or

[1917] hidden unique information placed into the root directory 3497 bof the fixed disk drive 668.

[1918]FIG. 69G shows an example of some of these appliance-specificsignatures.

[1919] In this example, machine signature information need not beparticularly large. Security is provided by hiding the machine signaturerather than on any other cryptographic strength, because there is nomore secure mechanism for key storage to protect it. Thus, it issatisfactory for the signature to be just large enough (e.g., two bytes)that it is unlikely to be duplicated by chance.

[1920] For some electronic appliances 600 where it can be determinedthat the technique is safe, an otherwise unused section of thenon-volatile CMOS RAM 656 a may be used to store a signature 3497 d.Signature 3497 d is verified against the PPE 650's internal statewhenever the PPE is initialized. Signature 3497 d may also be updatedwhenever a significant change is made to the secure database 610. If theCMOS RAM signature 3497 d does not match the database value, PPE 650 maytake this mismatch as an indication that a previous instance of thesecure database 610 and/or PPE 650 software has been restored, andappropriate action can be taken. This mechanism thus ensures that even abit-for-bit copy of the system's fixed disk 668 or other storage mediumcannot be saved and reloaded to restore an earlier PPE 650 state. Thisparticular technique depends upon there being an unused locationavailable within CMOS RAM 656 a, and may also require the CMOS RAMchecksum algorithm to be known. An incorrect implementation could causea subsequent reboot of electronic appliance 600 to fail because of a badCMOS checksum, or worse, could alter some critical configurationparameter within CMOS RAM 656 a so that electronic appliance 600 couldnot be recovered. Thus, care must be taken before modifying the contentsof CMOS RAM 656 a.

[1921] A still alternate technique may involve marking otherwise “good”disk sectors 3497 c defective and using the sectors) to store machinesignatures and/or encryption keys. This technique ensures that a logicalbit-for-bit copy of the media does not result in a usable PPE 650instance, and also provides relatively inaccessible and non-volatilestorage for the information. Because a relatively large amount ofstorage space can be reserved using this technique, there is enoughstorage for a cryptographically strong value.

[1922] Some of the “machine signature” techniques discussed above may beproblematic in some electronic appliances 600 because it may bedifficult to locate appropriate appliance-unique information. Forexample, although in a personal computer a ROM BIOS 658′ is alwaysavailable, the ROM BIOS information by itself may be insufficientbecause it is likely to be identical for a batch of electronicappliances 600 purchased together. Identifying a network adapter 666 anddetermining its address is potentially difficult due to the wide varietyof adapters; additionally, an electronic appliance's network address maychange (although this occurrence may be infrequent). Inserting randomsignature values into unused bytes within the fixed disk root directory3497 b and/or partition records may trigger some virus-checkingprograms, and the data may be modified by defragmentation or other diskmanipulation programs. Where supported, a truly unused disk sector 3497c (e.g., one that is marked “bad” even though it may still viably storeinformation) may be used to store the machine signature. Even so, normalmaintenance, upgrades or other failure recovery procedures may disrupt aparticular machine association. Since the VDE administrator 200 hparticipates in restoring a PPE 650 based on an encrypted backup image(as described above for example in connection with FIGS. 39-40), the VDEadministrator may establish new associations at this point to maintaincorrespondence between a particular PPE 650 installation and aparticular electronic appliance 600.

[1923] Tie Installation to Payment Method

[1924] A still additional example technique for providing additionalsecurity is to tie a particular PPE 650 installation at registrationtime to a particular payment method (see FIG. 69C, block 3470(8)). Theregistration process at installation time may thus serve to tie the PPE650 installation to some payment method associated with the user, and tostore the payment association information both within the PPE 650instance and at the registry 3476. This technique assures that theactions of a particular PPE 650 instance are accountable to the assigneduser with at least the reliability of whatever payment/creditverification technique is employed.

[1925] Install Operational Materials in Encrypted Form

[1926] Operational materials 3472 may first be customized as describedabove for the particular instance and/or appliance 600, then (at leastmostly) encrypted for installation into the appliance such as by storageonto disk 668 (see FIG. 69C, block 3470(9)). Different installations mayuse different sets of decryption keys to decrypt the information onceinstalled. Different parts of operational materials 3472 may beencrypted with different cryptographic keys to further complicate theanalysis. This encryption makes analysis of the on disk form of theoperational materials 3472 more difficult or infeasible.

[1927] The beginning of the resulting stored executable file may containa small decryption program (“decryptor”) that decrypts the remainder ofthe operational materials 3472 as they are loaded into memory.Confounding algorithms (as described below) may be used in thisdecryptor to make static recovery of the cryptographic keys difficult.Although the decryptor is necessarily in unencrypted form in anall-software installation without hardware support, the use ofconfounding algorithms to develop the associated cryptographic keyseffectively requires a memory image to be captured after the program hasbeen decrypted. Where supported (as described above), an unused andinaccessible disk sector 3497 c may be used to store the decryptionkeys, and the operational materials 3472 may possess only the addressfor that particular sector. Embedding this address further complicatesanalysis.

[1928] Customized Layout

[1929] The installation materials 3470 may store the encryptedoperational materials 3472 onto the fixed disk 668 using a customizedstorage layout (FIG. 69C, block 3470(10)). FIGS. 69F, 69H, 69I and 69Jshows example customized software and data layouts. In these examples,each installed instance of operational materials 3472 is different inboth executable form and in data layout. These modifications make eachPPE 650 instance require separate analysis in order to determine thestorage locations of its critical data such as cryptographic keys. Thistechnique is an effective counter to creation of programs that can undothe protections of an arbitrary PPE 650 instance.

[1930] Instruction sequences within the operational materials 3472 maybe modified by the installation routine to change the execution flow ofthe executable operational materials 3472 and to alter the locations atwhich the software expects to locate critical data. The alterations inprogram flow may include customization of time-consuming confoundingalgorithms. The locations of the modifiable instruction sequences may beembedded within operational materials 3470, and may therefore be notdirectly available from an examination of the installation and/oroperational materials.

[1931]FIG. 69H shows one example operational materials 3472 executablecode segment provided distinct processes 3498 a, 3498 b, 3498 c, 3498 d,3498 e. In this particular example, segment 3498 a is executed first andsegment 3498 e is executed last, but the processes 3498 b, 3498 c and3498 d may be performed in any order (i.e., they are sequenceindependent processes). The installation materials 3470 may takeadvantage of this sequence independence by storing and/or executing themin different and/or depending upon the particular PPE instance 650. FIG.69I, for example, shows a first static layout order, and FIG. 69J showsa second, different static layout order. Data elements associated withthe executables may similarly be stored in different orders (as shown inFIGS. 69I, 69J) depending upon the particular installation.

[1932] Dynamic Protection Mechanisms

[1933] In addition to the more static protection mechanisms describedabove, dynamic protection mechanisms may be employed to complicate bothstatic and dynamic analysis of the executable (executing) operationalmaterials 3472. Such techniques include, for example:

[1934] implementation complexity,

[1935] immediate overwriting,

[1936] hardware dependent sequences,

[1937] timing dependencies,

[1938] confounding algorithms,

[1939] random modifications,

[1940] dynamic load module decryption,

[1941] on-line integrity checks,

[1942] time integrity checks,

[1943] machine association integrity checks,

[1944] dynamic storage integrity checks, and

[1945] hidden secret storage

[1946] volatile secret storage

[1947] internal consistency checks.

[1948] FIGS. 69K-69L show an example execution of operational materials3472 that may employ some or all of these various dynamic protectionmechanisms. Upon starting execution (FIG. 69K, block 3550), theinstalled operational materials 3472 may run initialization code asdescribed above that is used to decrypt the stored encrypted operationalmaterials on an “as needed” basis (FIG. 69K, block 3552). Thisinitialization code may also check the current value of the real-timeclock (FIG. 69K block 3554).

[1949] Real Time Check/Validation

[1950] Operational materials 3472 may perform this time check, forexample, to guard against replay attacks and to ensure that theelectronic appliance 600's time is in reasonable agreement with that ofthe VDE administrator 200 h or other trusted node.

[1951]FIG. 69M shows an example sequence of steps that may be performedby the “check time” block 3554. In this example, PPE 650 uses securecommunications (e.g. a cryptographic protocol) to obtain the currentreal time from a trusted server (FIG. 69M, block 3554 a). PPE 650 maynext ask the user if he or she wishes to reset the electronic appliancereal-time clock 528 (which may, for example, be the real-time clockmodule within a personal computer or the like) so it is synchronizedwith the trusted server's time clock.

[1952] If the user responds affirmatively, PPE 650 may reset the timeclock to agree with the real-time provided by the trusted server (“yes”exit to decision block 3554 b, FIG. 69M, block 3554 c). If the userresponds that he or she does not want the real-time clock reset (“no”exit to decision block 3554 b), then PPE 650 may calculate a delta valueof the difference between the server's real-time clock and theelectronic appliance's real-time clock 528 (FIG. 69M, block 3554 d). Ineither case, PPE 650 may store the current time Tcurrent into anon-volatile storage location Tstore indicating the current real-time(FIG. 69M, block 3554 e).

[1953] Referring again to FIG. 69K, PPE 650 can disable itself if thereis too much (or the wrong type) of a difference between the trustedserver's time and the electronic appliance's clock—since suchdifferences can indicate replay attacks, the possibility that the PPE650 has been restored based on a previous state, etc. For example, ifdesired, PPE 650 can generate a time check fail exception if theelectronic appliance's real-time clock 528 disagrees with the trustedserver's real-time by more than a certain amount of acceptable drift(FIG. 69K, “yes” exit to decision block 3556). In the event of such anexception, PPE 650 may disable itself (FIG. 69K, block 3558) and requirea dialog between the user and registry 3476 (or otherauthority)—providing additional protection against replay attacks andalso detecting clock failures that could lead to incorrect operation orincorrect charges.

[1954] Dynamic Code Decryption and Data OverWriting

[1955] Operational materials 3472 may then decrypt the next programsegment dynamically (FIG. 69K block 3460. The code may be decrypteddynamically when it is needed, then re-encrypted or overwritten anddiscarded when not in use. This mechanism increases thetamper-resistance of the executable code—thus providing additionaltamper resistance for PPE operations. As mentioned above, differentdecryption keys may be required to decode different code portions, andthe decryption keys can be installation-specific so that an attacker whosuccessfully comprises the decryption key of one instance cannot usethat information to compromise any other instance's decryption key(s).

[1956] Once a portion of the operational materials 3472 has beendecrypted (FIG. 69K block 3560), that portion may immediately overwriteall initialization code in memory since it is no longer required (FIG.69K, block 3562). The executing operational materials 3472 may similarlyoverwrite all unwrapped cryptographic keys once they are no longerneeded, and may also overwrite expanded key information developed byinitializing the cryptographic algorithms once no longer needed. Thesetechniques minimize the amount of time during which usable keyinformation is available for exposure in a memory snapshot—complicatingall but the most dynamic of analysis efforts. Because all keys inpermanent storage are either encrypted or otherwise camouflaged, no suchtreatment is required for I/O buffers.

[1957] Dynamic Check of Association between Appliance and PPE Instance

[1958] The executing operational materials 3472 may next compare anembedded electronic appliance signature SIG′ against the electronicappliance signature SIG stored in the electronic appliance itself (FIG.69K, decision block 3564). As discussed above, this technique may beused to help prevent operational materials 3472 from operating on anyelectronic appliance 600 other than the one it was initially installedon. PPE 650 may disable operation if this machine signature check fails(“no” exit to decision block 3564, FIG. 69K; disable block 3566).

[1959] Self-Modifying and/or Hardware-Dependent Code Sequences

[1960] Executing operational materials 3472 may also employself-modifying code sequences that cannot easily be emulated with asoftware debugger or single-stepping program (FIG. 69K, block 3568).These sequences may, for example, be dependent on specific models ofelectronic appliances 600, and may be patched into the operationalmaterials 3472 as appropriate to installation materials 3470 based ontests performed during the installation process. Such hardware-dependentsequences may be used to ensure that critical algorithms yield differentresults when executed on the proper hardware as opposed to when executedon different hardware or under software control such as in a debugger oremulator. To prevent such hardware-dependent sequences from beingreadily recognizable from a static examination of the code, thesequences may be constructed at run time and then invoked—so that theycan be identified only by analysis of the instruction sequences actuallyexecuted.

[1961] Dynamic Timing Checks

[1962] Executing operational materials 3472 may also make dynamic timingchecks on various code sequences, and refuse to operate if they do notexecute within the expected interval (FIG. 69K, block 3570, decisionblock 3572, “disable” block 3574).. An incorrect execution time suggeststhat the operational materials 3472 are being externally manipulatedand/or analyzed or traced in some manner (e.g., by a software emulator).This technique thus provides additional protection against dynamicanalysis and/or modification

[1963] The expected execution intervals associated with certain codesequences may be calculated during the installation procedure. Resultingtest values may be embedded into the operational materials 3472. Thesetiming tests may be integrated with time integrity tests and dynamicintegrity checks to make it more difficult to bypass them simply bypatching out the timing check. Care should be taken to eliminate falsealarms due to concurrent system activity (e.g., other tasks and/orwindows)..

[1964]FIG. 69N shows one example of a dynamic time check routine 3570.In this example, a test may be performed to determine whether it is timeto perform another time check (decision block 3570 a). For example, thistest 3570 a may be performed periodically and/or at the end of atime-dependent sequence as described above. If performed periodically, acounter V value may be incremented or reset to zero—readying thiscounter for the next performance of test 3470A (see FIG. 69N, block 3570b, 3570 c, 3570 d).

[1965] If it is time to perform a check, PPE 650 compares the storedtime value Tstore with the current time value Tcurrent, and determineswhether the two values are within an acceptable range (FIG. 69N,decision block 3570E). If the two values agree within an acceptablerange (this range may be determined, for example, in part by thetime-dependent testing described above), then PPE 650 may replace thestored time value Tstore with the current Tcurrent in preparation forthe next test (FIG. 69N, block 3570F). If, on the other hand, the twovalues are not within an acceptable range (the “not within range” exitto decision block 3570E, FIG. 69N), PPE 650 may disable operation (block3570G) and initiate a conversation with a trusted time base or otherverification facility to perform further authenticity checking (FIG.69N, block 3570H). As FIG. 69L shows, further time checks may beperformed periodically and/or repeatedly based on other events (seeblock 3582, decision block 3584, disable block 3586).

[1966] Confounding Algorithms

[1967] The executing operational materials 3472 may also perform variousconfounding algorithms—computationally intensive algorithms that performa complex operation in order to generate values required at run time(FIG. 69L, block 3576). The purpose of such confounding algorithms is tomake infrequently invoked steps (e.g., initialization or other steps notperformed very frequently) inscrutable to an attacker who isdisassembling or tracing them. Confounding algorithms may also be usedfor the time-dependent checking described above.

[1968] One example of such a “confounding algorithm” is a modifiedversion of the MD5 message digest function (applied repeatedly to thesame input value), which tests internally generated results of the roundfunctions and terminates when a specific value is encountered. Forexample, one may make random modifications to the confounding algorithm(for example, by adjusting the “magic constants” in MD5) until itterminates quickly enough to be useful with the desired value in someregister. This adjustment may be performed beforehand to yield a priorknowledge of modifications that can then be installed differently and toeach PPE 650 instance.

[1969] As one specific example, a family of 256 customized confoundingalgorithms could be created, each defined by a single modification ofthe MD5 “magic constants” (or even the input data to MD5) so that thealgorithm terminates with any of 256 possible values in some register.Critical values can then be generated at run time by installingappropriate versions of the algorithm into the operational materials3472 and assembling the values a byte at a time. Confounding algorithmsmay be performed in a time-dependent value as described above; theirexecution times may be logged and checked by PPE 650, and the PPE 650may disable operation if the confounding algorithms run too rapidly orslowly.

[1970] Such confounding algorithms are generally infeasible to simulateby hand because they may require tens or hundreds of millions ofinstructions to complete. They are expensive to analyze at run timebecause single-stepping through the code is time consuming (though notprohibitive, particularly if break points are set at all the possibletermination tests rather than for every instruction). Although suchconfounding algorithms are expensive in computation time, then need notbe invoked frequently—preserving efficiency.

[1971] Random Modifications to Environment State

[1972] The executing operational materials 3472 may randomly modify thePPE 650 environment state during normal operation to reflect both actualPPE 650 operations being performed and to include random modificationsof data not significant to the operating PPE 650 (FIG. 69L, block 3578).Such techniques help ensure that snapshots of the secure database 610and operational materials 3472 cannot readily be compared to identifysignificant values and objects.

[1973] Such modifications may be based, for example, on actual randomvalues derived from unpredictable hardware events such as disk I/Ocompletion timing and keyboard timing. Such techniques make itinfeasible to experiment with “minor” changes to the PPE 650 state evenif the attacker can successfully bypass integrity checks that preventduplicates from being made.

[1974] Load Module Dynamic Decryption & Re-Encryption

[1975] The executing operational materials 3472 may decrypt load module1100 code dynamically as needed, and re-encrypt it or otherwise renderit inscrutable when not in use (FIG. 69L, block 3580). In accordancewith this technique, load module executable code and/or data isdecrypted dynamically when it is needed, then re-encrypted or destroyedwhen not in use. In addition, the location of executing load modules1100 may be varied randomly to foil attempts to set break points withinthe load module. Different algorithms and a changing key may be used tofurther confound dynamic analysis.

[1976] Hidden Secret Storage

[1977] The source database 610 and/or parts or all of operationalmaterials 3472 may be protected by cryptography employing keys and/orauthentication values hidden in normally inaccessible locations in theappliance 600. If the key or authentication value is not available, thedecryption cannot be performed, rendering PPE 650 unusable. Examples ofsuch locations include, but are not limited to:

[1978] Disk storage artificially marked as damaged (for the purpose ofstoring secrets);

[1979] Disk storage normally reserved as alternates for sectors that maybe marked as damaged;

[1980] Disk storage normally reserved for non-general purpose use, suchas sectors reserved by the manufacturer for firmware storage, forstorage of statistics, or for test purposes, etc.;

[1981] Non-volatile, writable, storage in the appliance or itscomponents, such as that used for configuration data, device andcontrolled firmware, standard BIOS software, etc;

[1982] Unused storage in files maintained by an operating system, suchas the bytes between the logical end of a file and the end of its lastphysical sector, etc.;

[1983] Unused storage in file system control structures, such as thebytes available to store as-yet-undefined attributes, unused storage infile allocation maps and other structures, unused storage in redundant(duplicate) file maps and directories, unused or unneeded bytes in bootrecords, etc.;

[1984] Storing secrets (e.g., cryptographic keys and authenticationvalues) in these locations serves two purposes: it makes them difficultto locate by analysis of the PPE 650, and it makes them difficult tocopy between one instance of the PPE and another (or to replace thePPE's contents with an earlier version of the same).

[1985] Volatile Secret Storage

[1986] The secure database 610 and/or parts or all of operationalmaterials 3472 may be protected by cryptography employing keys and/orauthentication values (“cryptovariables”) that are maintained only involatile storage during normal operation. For example, during aninitialization sequence, cryptovariables can be read from permanentstorage (e.g., disk), overwritten, and held only in volatile memoryduring system operation. During the shutdown sequence, thecryptovariables can be rewritten to permanent storage.

[1987] This provides resistance to tampering because the initializationsequence for an appliance, particularly a general-purpose computer, istypically more difficult to tamper with than is the computer duringnormal operation. This technique prevents the computer from itself beingused to analyze the contents of permanent storage media; only byremoving the media and analyzing it independently can thecryptovariables be located and extracted. This technique has thedrawback of requiring the appliance's operation always to be terminatednormally so that the termination sequence is guaranteed to update thepermanent storage. This drawback can be ameliorated by maintainingfrequent backups of the secure database 610 and/or the protectedcrypto-variables that can be restored with administration by VDEadministrator 200 h if a disorderly termination occurs.

[1988] Dynamic Integrity Checks

[1989] In this example, operational materials 3472 may also perform avariety of dynamic integrity checks that tie an executing PPE 650 to aparticular electronic appliance 600 and to guard against various formsof replay or substitution attacks. One example of a replay attack, forexample, is an attack in which a user restores the PPE 650 state from anearlier backup—wiping out all recent billing records. PPE 650 includes abackup mechanism (as discussed above in connection with FIGS. 39 and 40)that supports restoration of previous states after system failure.Executing operational materials 3472 in this example provides certaindynamic protection mechanisms (integrity checks) that prevent suchbackup and restoration processes from being misused to allow such replayattacks. Such checks may identify incomplete or erroneous attempts tosubvert tamper resistant barrier 672. Great care must be taken to ensurethat these checks do not trigger as a result of execution orimplementation error, as there is potential for significant disruption.

[1990] For example, during PPE 650 operation, the internal state of thePPE is constantly being updated. During each interaction with a trustedserver, PPE 650 (and the trusted server) may test the internal state ofPPE 650 to determine whether it could be derived from the internal statelast seen by the trusted server for this particular PPE 650 instance. Ifit could not, the result may be taken as indicating a replay attack ofsome sort, and an appropriate action can be taken (see FIG. 69L, block3592, 3594, 3596).

[1991] For example, such a check could be implemented using a counterstored in PPE 650 and updated every time an operation is performed. Ifthe trusted server finds the counter to be smaller than at the previousserver interaction, this finding is strong evidence that a previousstate of the PPE 650 environment has been restored. In practice, thecheck might be implemented with an obscure technique to prevent easymanipulation of the counter value. For example, the counter could berepeated hashing (e.g., with MD5) of a value that is stored redundantlyin several different locations within the operational materials 3472 andsecure database 610—so that the trusted server could verify that thecurrent value can be derived (e.g., by repeated MD5 applications) from aprevious value. Such checks may limit the severity of loss resultingfrom off-line manipulation of PPE 650. Because the trusted serververifies the consistency of PPE 650 at each interaction, the only lossthat may occur as a result of wholesale reloading of an earlier PPE 650state is that of content that has already been delivered by has not yetbeen charged for.

[1992] One example of a dynamic integrity check that executingoperational materials 3472 may perform (FIG. 69L, block 3588) might, forexample, be the periodic verification of the integrity of theoperational materials code in memory by a checksum invoked by a timer.If the timer does not tick regularly, the PPE 650 may detect it andcease to operate (see FIG. 69N). This verification may counter attacksthat might, for example, attempt to trick PPE 650 access methods intoreleasing content that has been decrypted but not electronicallyfingerprinted. Executing operational materials 3472 may also includenumerous internal consistency checks to prevent substitution (replay) ofstale database 610 records, introduction of invalid load modules 1100,external modification of the secure database 610, and so on. Such checksmay be made sufficiently complex and interwoven as to make modificationslikely to be detected.

[1993] When an inconsistency is detected (“yes” exit to decision block3590, FIG. 69L), PPE 650 can take appropriate action such as lockingitself up from further use until reconstructed under the trustedserver's control (FIG. 69L, disable block 3591). For example, PPE 650could encrypt its secure database 610 with a new, random key, thenencrypt that with the server's public key. Only the server could thenarrange to reconstruct the user's instance of PPE 650.

[1994] Defense in Depth

[1995] Finally, although not a “camouflage” technique per se, thecomplexity of operational materials 3472 may make it difficult tounderstand them from the outside in. As discussed above, PPE 650 maymake extensive use of RPC and coordinated work in different threads ofexecution. Because much of the RPC traffic may be encrypted, it will bedifficult to unravel even if operational materials 3472 are heavilyinstrumented by the attacker. Although the cryptographic keys are, inprincipal, readily available in memory (e.g., because after all, the PPE650 must be able to get them), there may be many keys and it will bedifficult to identify the right one rapidly. In addition, a primarybenefit to be sought by subverting protection of software-based PPE 650installations is the ability to acquire content without paying for it—inother words, the ability to “create money”. The integrity checksdiscussed above mean that any error in manipulating the budget and usageinformation data is likely to be detected quickly. Even if the checksoccur off-line without notification to any trusted server, it will makethe user's PPE 650 instance effectively useless—requiring itsdestruction and recreation.

[1996] Networking SPUs 500 and/or VDE Electronic Appliances 600

[1997] In the context of many computers interconnected by a local orwide area network, it would be possible for one or a few of them to beVDE electronic appliances 600. For example, a VDE-capable server mightinclude one or more SPUs 500. This centralized VDE server could provideall VDE services required within the network or it can share VDE servicewith VDE server nodes; that is, it can perform a few, some, or most VDEservice activities. For example, a user's non-VDE computer could issue arequest over the network for VDE-protected content. In response to therequest, the VDE server could comply by accessing the appropriate VDEobject 300, releasing the requested content and delivering the contentover the network 672 to the requesting user. Such an arrangement wouldallow VDE capabilities to be easily integrated into existing networkswithout requiring modification or replacement of the various computersand other devices connected to the networks.

[1998] For example, a VDE server having one or more protected processingenvironments 650 could communicate over a network with workstations thatdo not have a protected processing environment. The VDE server couldperform all secure VDE processing, and release resulting content andother information to the workstations on the network. This arrangementwould require no hardware or software modification to the workstations.

[1999] However, some applications may require greater security,flexibility and/or performance that may be obtained by providingmultiple VDE electronic appliances 600 connected to the same network672. Because commonly-used local area networks constitute an insecurechannel that may be subject to tampering and/or eavesdropping, it isdesirable in most secure applications to protect the informationcommunicated across the network. It would be possible to useconventional network security techniques to protect VDE-released contentor other VDE information communicated across a network 672 between a VDEelectronic appliance 600 and a non-VDE electronic appliance. However,advantages are obtained by providing multiple networked VDE electronicappliances 600 within the same system.

[2000] As discussed above in connection with FIG. 8, multiple VDEelectronic appliances 600 may communicate with one another over anetwork 672 or other communications path. Such networking of VDEelectronic appliances 600 can provide advantages. Advantages include,for example, the possibility of centralizing VDE resources, storingand/or archiving metering information on a server VDE and deliveringinformation and services efficiently across the network 672 to multipleelectronic appliances 600.

[2001] For example, in a local area network topology, a “VDE server”electronic appliance 600 could store VDE-protected information and makeit available to one or more additional electronic appliances 600 orcomputers that may communicate with the server over network 672. As oneexample, an object repository 728 storing VDE objects could bemaintained at the centralized server, and each of many networkedelectronic appliance 600 users could access the centralized objectrepository over the network 672 as needed. When a user needs to access aparticular VDE object 300, her electronic appliance 600 could issue arequest over network 672 to obtain a copy of the object. The “VDEserver” could deliver all or a portion of the requested object 300 inresponse to the request. Providing such a centralized object repository728 would have the advantage of minimizing mass storage requirementslocal to each electronic appliance 600 connected to the network 672,eliminate redundant copies of the same information, ease informationmanagement burdens, provide additional physical and/or other securityfor particularly important VDE processes and/or information occurring atthe server, where providing such security at VDE nodes may becommercially impractical for certain business models, etc.

[2002] It may also be desirable to centralize secure database 610 in alocal area network topology. For example, in the context of a local areanetwork, a secure database 610 server could be provided at a centralizedlocation. Each of several electronic appliances 600 connected to a localarea network 672 could issue requests for secure database 610 recordsover the network, and receive those records via the network. The recordscould be provided over the network in encrypted form. “Keys” needed todecrypt the records could be shared by transmitting them across thenetwork in secure communication exchanges. Centralizing secure database610 in a network 672 has potential advantages of minimizing oreliminating secondary storage and/or other memory requirements for eachof the networked electronic appliances 600, avoiding redundantinformation storage, allowing centralized backup services to beprovided, easing information management burdens, etc.

[2003] One way to inexpensively and conveniently deploy multipleinstances of VDE electronic appliances 600 across a network would be toprovide network workstations with software defining an HPE 655. Thisarrangement requires no hardware modification of the workstations; anHPE 655 can be defined using software only. An SPE(s) 503 and/or HPE(s)655 could also be provided within a VDE server. This arrangement has theadvantage of allowing distributed VDE network processing withoutrequiring workstations to be customized or modified (except for loadinga new program(s) into them). VDE functions requiring high levels ofsecurity may be restricted to an SPU-based VDE server. “Secure”HPE-based workstations could perform VDE functions requiring lesssecurity, and could also coordinate their activities with the VDEserver.

[2004] Thus, it may be advantageous to provide multiple VDE electronicappliances 600 within the same network. It may also be advantageous toprovide multiple VDE electronic appliances 600 within the sameworkstation or other electronic appliance 600. For example, anelectronic appliance 600 may include multiple electronic appliances 600each of which have a SPU 500 and are capable of performing VDEfunctions.

[2005] For example, one or more VDE electronic appliances 600 can beused as input/output device(s) of a computer system. This may eliminatethe need to decrypt information in one device and then move it inunencrypted form across some bus or other unsecured channel to anotherdevice such as a peripheral. If the peripheral device itself is a VDEelectronic appliance 600 having a SPU 500, VDE-protected information maybe securely sent to the peripheral across the insecure channel forprocessing (e.g., decryption) at the peripheral device. Giving theperipheral device the capability of handling VDE-protected informationdirectly also increases flexibility. For example, the VDE electronicappliance 600 peripheral device may control VDE object 300 usage. Itmay, for example, meter the usage or other parameters associated withthe information it processes, and it may gather audit trials and otherinformation specific to the processing it performs in order to providegreater information gathering about VDE object usage. Providing multiplecooperating VDE electronic appliances 600 may also increase performanceby eliminating the need to move encrypted information to a VDEelectronic appliance 600 and then move it again in unencrypted form to anon-VDE device. The VDE-protected information can be moved directly toits destination device which, if VDE-capable, may directly process itwithout requiring involvement by some other VDE electronic appliance600.

[2006]FIG. 70 shows an example of an arrangement 2630 comprisingmultiple VDE electronic appliances 600(1), 600(2), 600(3), . . . ,600(N). VDE electronic appliances 600(1) . . . 600(N) may communicatewith one another over a communications path 2631 (e.g., the system busof a work station, a telephone or other wire, a cable, a backplane, anetwork 672, or any other communications mechanism). Each of theelectronic appliances 600 shown in the figure may have the same generalarchitecture shown in FIG. 8, i.e., they may each include a CPU (ormicrocontroller) 654, SPU 500, RAM 656, ROM 658, and system bus 653.Each of the electronic appliances 600 shown in the figure may have aninterface/controller 2632 (which may be considered to be a particularkind of I/O controller 660 and/or communications controller 666 shown inFIG. 8). This interface/controller 2632 provides an interface betweenthe electronic appliance system bus 653 and an appropriate electricalconnector 2634. Electrical connectors 2634 of each of the respectiveelectronic appliances 600(1), . . . 600(N) provide a connection to acommon network 672 or other communication paths.

[2007] Although each of electronic appliances 600 shown in the figuremay have a generally similar architecture, they may perform differentspecialized tasks. For example, electronic appliance 600(1) mightcomprise a central processing section of a workstation responsible formanaging the overall operation of the workstation and providingcomputation resources. Electronic appliance 600(2) might be a massstorage device 620 for the same workstation, and could provide a storagemechanism 2636 that might, for example, read information from and writeinformation to a secondary storage device 652. Electronic appliance600(3) might be a display device 614 responsible for performing displaytasks, and could provide a displaying mechanism 2638 such as a graphicscontroller and associated video or other display. Electronic appliance600(N) might be a printer 622 that performs printing related tasks andcould include, for example, a print mechanism 2640.

[2008] Each of electronic appliances 600(1), . . . 600(N) could comprisea different module of the same workstation device all contained within acommon housing, or the different electronic appliances could be locatedwithin different system components. For example, electronic appliance600(2) could be disposed within a disk controller unit, electronicappliance 600(3) could be disposed within a display device 614 housing,and the electronic appliance 600(N) could be disposed within the housingof a printer 622. Referring back to FIG. 7, scanner 626, modem 618,telecommunication means 624, keyboard 612 and/or voice recognition box613 could each comprise a VDE electronic appliance 600 having its ownSPU 500. Additional examples include RF or otherwise wireless interfacecontroller, a serial interface controller, LAN controllers, MPEG (video)controllers, etc.

[2009] Because electronic appliances 600(1) . . . 600(N) are eachVDE-capable, they each have the ability to perform encryption and/ordecryption of VDE-protected information. This means that informationcommunicated across network 672 or other communications path 2631connecting the electronic appliances can be VDE-protected (e.g., it maybe packaged in the form of VDE administrative and/or content objects andencrypted as discussed above). One of the consequences of thisarrangement is that an eavesdropper who taps into communications path2631 will not be able obtain information except in VDE-protected form.For example, information generated by electronic appliance 600(1) to beprinted could be packaged in a VDE content object 300 and transmittedover path 2631 to electronic appliance 600(N) for printing. An attackerwould gain little benefit from intercepting this information since it istransmitted in protected form; she would have to compromise electronicappliance 600(1) or 600(N) (or the SPU 500(1), 500(N)) in order toaccess this information in unprotected form.

[2010] Another advantage provided by the arrangement shown in thediagram is that each of electronic appliances 600(1), . . . 600(N) mayperform their own metering, control and/or other VDE-related functions.For example, electronic appliance 600(N) may meter and/or perform anyother VDE control functions related to the information to be printed,electronic appliance 600(3) may meter and/or perform any other VDEcontrol functions related to the information to be displayed, electronicappliance 600(2) may meter and/or perform any other VDE controlfunctions related to the information to be stored and/or retrieved frommass storage 620, and electronic appliance 600(1) may meter and/orperform any other VDE control functions related to the information itprocesses.

[2011] In one specific arrangement, each of electronic appliances600(1), . . . 600(N) would receive a command that indicates that theinformation received by or sent to the electronic appliance is to useits SPU 500 to process the information to follow. For example,electronic appliance 600(N) might receive a command that indicates thatinformation it is about to receive for printing is in VDE-protected form(or the information that is sent to it may itself indicate this). Uponreceiving this command or other information, electronic appliance 600(N)may decrypt the received information using SPU 500, and might also meterthe information the SPU provides to the print mechanism 2644 forprinting. An additional command might be sent to electronic appliance600(N) to disable the decryption process or 600(N)'s VDE securesubsystem may determine that the information should not be decryptedand/or printed. Additional commands, for example, may exist to loadencryption/decryption keys, load “limits,” establish “fingerprinting”requirements, and read metered usage. These additional commands may besent in encrypted or unencrypted form as appropriate.

[2012] Suppose, for example, that electronic appliance 600(1) producesinformation it wishes to have printed by a VDE-capable printer 622. SPU500(1) could establish a secure communications across path 2631 with SPU500(N) to provide a command instructing SPU 500(N) to decrypt the nextblock of data and store it as a decryption key and a limit. SPU 500(1)might then send a further command to SPU 500(N) to use the decryptionkey and associated limit to process any following encrypted print stream(or this command could be sent by CPU 654(1) to microcontroller 654(N)).Electronic appliance 600(1) could then begin sending encryptedinformation on path 672 for decryption and printing by printer 622. Uponreceipt of each new block of information by printer 622, SPU 500(N)might first check to ensure that the limit is greater than zero. SPU500(N) could then increment a usage meter value it maintains, anddecrement the limit value. If the limit value is non-zero, SPU 500(N)could decrypt the information it has received and provide it to printmechanism 2640 for printing. If the limit is zero, then SPU 500(N) wouldnot send the received information to the print mechanism 2640, nor wouldit decrypt it. Upon receipt of a command to stop, printer 622 couldrevert to a “non-secure” mode in which it would print everythingreceived by it across path 2631 without permitting VDE processing.

[2013] The SPU 500(N) associated with printer 622 need not necessarilybe disposed within the housing of the printer, but could instead beplaced within an I/O controller 660 for example (see FIG. 8). This wouldallow at least some of the advantages similar to the ones discussedabove to be provided without requiring a special VDE-capable printer622. Alternatively, a SPU 500(N) could be provided both within printer622 and within I/O controller 660 communicating with the printer toprovide advantages in terms of coordinating I/O control and relievingprocessing burdens from the SPU 500 associated with the centralprocessing electronic appliance 600(1). When multiple VDE instancesoccur within an electronic appliance, one or more VDE secure subsystemsmay be “central” subsystems, that is “secondary” VDE instances may passencrypted usage related information to one or more central securesubsystems so as to allow said central subsystem to directly controlstorage of said usage related information. Certain control informationmay also be centrally stored by a central subsystem and all or a portionof such information may be securely provided to the secondary securesubsystem upon its secure VDE request.

[2014] Such printer protections as described above may be particularlyuseful, for example, in the case of content providers that want torestrict or otherwise control (e.g., charge for) printing of theircontent. These controls can be easily enforced in the case of printersas described above having SPUs 500 (PPEs 650), but may be difficult toenforce in the case of general-purpose printers that do not have an SPU(PPE). It may be relatively easy in such environments to use printerredirectors, print output to a file, or otherwise manipulate thesystem's printing functions. It therefore may be advantageous to providea strategy that protects printed outputs in such general purposeprinting environments. So-called “intelligent” printers are capable ofexecuting “scripts” or other programs comprising executable instructionsor commands. Such “script” languages can be used to provide a degree oftamper-resistance and security without the necessity of an SPU 500 (PPE650).

[2015] For example, it is possible to create a decryption program 3900,in PostScript or another printer control language, that can bedownloaded 3801 to an associated printer 3901, creating a program 3904stored inside the memory of printer 3901. Because PostScript, as well asother similar printer control languages, is a general-purposeprogramming language, such a program could decrypt (3802) an encrypteddata stream 3902 sent to such a printer 3901. This approach would allowa local PPE 650 to prepare (3800) files for printing inside the PPE bycreating an encrypted file 3902 to be printed and delivering it forprocessing by the decryption program inside the printer.

[2016] The decryption program 3900 could be downloaded (3801) as aprinter initialization activity. Using features of the PostScript orother language, and/or other mechanisms in the printer, the decryptionprogram 3904 could be locked into the memory 3901 m of printer 3901 soit could not be viewed and/or modified except with appropriateauthorization. The downloaded decryption program 3904 could engage in aninteractive secure protocol dialogue (3802) with PPE 650 to demonstratethat it has not been tampered with, as a precondition to creating anddelivering the encrypted printable content 3902. The decryption program3900 could also be downloaded (3801) to printer 3901 prior to printingone or more encrypted content streams 3902. The decryption program 3904could destroy itself after printing one or more encrypted contentstreams 3902 to protect itself against viewing or tampering.

[2017] As shown in FIG. 70B, the decryption program 3900 couldalternatively or additionally provide a fingerprinting function—forexample by selecting characters for printing from several relatedcharacter fonts (3910 a-3910 z) in a pattern 3911 that is generated froma fingerprint key 3912 using standard cryptographic and/orsteganographic techniques. Because each of the characters 3913 aa, 3913ba, etc. representing the letter “A” in fonts 3910 a-3910 z is printedwith a slightly different image, it is possible to identify the fontfrom which each character was drawn by careful examination of theprinted output, and thus to reconstruct the pattern 3911 and from thatthe fingerprint key 3912. There are similarly different patterns forother characters in fonts 3910 a-3910 z, shown as 3913 ab-3913 zb, etc.,permitting a more efficient and/or tamper-resistant encoding offingerprint information.

[2018] For printers that use non-executable control languages, such asPCL5, scrambled fonts can be used without requiring that a decryptionprogram be downloaded or otherwise installed in the printer. As shown inFIG. 70, it is possible download permuted font images 3921 to suchprinters. Scrambled fonts 3921 are created by rearranging the characterimages in a normal font 3920. Such fonts allow PPE 650 to scramble thedata before it is delivered for printing, so that it could not be easilyinterpreted except by being printed on a printer with appropriatescrambled fonts. As a simple substitution cipher, this could be invertedusing automated techniques, but it provides good security againstaccidental disclosure. Plural scrambled fonts 3921, scrambled accordingto different patters, could be resident simultaneously in the printer,and used for different sections of the printed content or differentpages. Scrambled fonts 3921 could be downloaded and/or replaceddynamically in the printer differently for each page or other divisionin the output.

[2019] The technique of using multiple character images forfingerprinting shown in FIG. 70B is also applicable to printersincorporating non-executable control languages, by downloading multiplefonts 3910 a-z incorporating different images for characters.

[2020] Portable Electronic Appliance

[2021] Electronic appliance 600 provided by the present invention may beportable. FIG. 71 shows one example of a portable electronic appliance2600. Portable appliance 2600 may include a portable housing 2602 thatmaw be about the size of a credit card in one example. Housing 2602 mayconnect to the outside world through, for example, an electricalconnector 2604 having one or more electrical contact pins (not shown).Connector 2604 may electrically connect an external bus interface 2606internal to housing 2602 to a mating connector 2604 a of a host system2608. External bus interface 2606 may, for example, comprise a PCMICIA(or other standard) bus interface to allow portable appliance 2600 tointerface with and communicate over a bus 2607 of host system 2608. Host2608 may, for example, be almost any device imaginable, such as acomputer, a pay telephone, another VDE electronic appliance 600, atelevision, an arcade video game, or a washing machine, to name a fewexamples.

[2022] Housing 2602 may be tamper resistant. (See discussion aboverelating to tamper resistance of SPU barrier 502.)

[2023] Portable appliance 2600 in the preferred embodiment includes oneor more SPUs 500 that may be disposed within housing 2602. SPU 500 maybe connected to external bus interface 2606 by a bus 2610 internal tohousing 2602. SPU 500 communicates with host 2608 (through external businterface 2606) over this internal bus 2610.

[2024] SPU 500 may be powered by a battery 2612 or other portable powersupply that is preferably disposed within housing 2602. Battery 2612 maybe, for example, a miniature battery of the type found in watches orcredit card sized calculators. Battery 2612 may be supplemented (orreplaced) by solar cells, rechargeable batteries, capacitive storagecells, etc.

[2025] A random access memory (RAM) 2614 is preferably provided withinhousing 2602. RAM 2614 may be connected to SPU 500 and not directlyconnected to bus 2610, so that the contents of RAM 2614 may be accessedonly by the SPU and not by host 2608 (except through and as permitted bythe SPU). Looking at FIG. 9 for a moment, RAM 2614 may be part of RAM534 within the SPU 500, although it need not necessarily be containedwithin the same integrated circuit or other package that houses the restof the SPU.

[2026] Portable appliance 2600 RAM 534 may contain, for example,information which can be used to uniquely identify each instance of theportable appliance. This information may be employed (e.g. as at least aportion of key or password information) in authentication, verification,decryption, and/or encryption processes.

[2027] Portable appliance 2600 may, in one embodiment, comprise means toperform substantially all of the functions of a VDE electronic appliance600. Thus, for example, portable appliance 2600 may include the meansfor storing and using permissions, methods, keys, programs, and/or otherinformation, and can be capable of operating as a “stand alone” VDEnode.

[2028] In a further embodiment, portable appliance 2600 may performpreferred embodiment VDE functions once it has been coupled to anadditional external electronic appliance 600. Certain information, suchas database management permission(s), method(s), key(s), and/or otherimportant information (such as at least a portion of other VDE programs:administrative, user-interface, analysis, etc.) may be stored (forexample as records) at an external VDE electronic appliance 600 that mayshare information with portable appliance 2600.

[2029] One possible “stand alone” configuration for tamper-resistant,portable appliance 2600 arrangements includes a tamper-resistant package(housing 2602) containing one or more processors (500, 2616) and/orother computing devices and/or other control logic, along withrandom-access-memory 2614. Processors 500, 2616 may execute permissionsand methods wholly (or at least in part) within the portable appliance2600. The portable appliance 2600 may have the ability to encryptinformation before the information is communicated outside of thehousing 2602 and/or decrypt received information when said receivedinformation is received from outside of the housing. This version wouldalso possess the ability to store at least a portion of permission,method, and/or key information securely within said tamper resistantportable housing 2602 on non-volatile memory.

[2030] Another version of portable appliance 2600 may obtain permissionsand/or methods and/or keys from a local VDE electronic appliance 600external to the portable appliance 2600 to control, limit, or otherwisemanage a user's use of a VDE protected object. Such a portable appliance600 may be contained within, received by, installed in, or directlyconnected to, another electronic appliance 2600.

[2031] One example of a “minimal” configuration of portable appliance2600 would include only SPU 500 and battery 2612 within housing 2602(the external bus interface 2606 and the RAM 2614 would in this caseeach be incorporated into the SPU block shown in the Figure). In other,enhanced examples of portable appliance 2600, any or all of thefollowing optional components may also be included within housing 2602:

[2032] one or more CPUs 2616 (with associated support components such asRAM-ROM 2617, I/O controllers (not shown), etc.);

[2033] one or more display devices 2618;

[2034] one or more keypads or other user input buttons/controlinformation 2620;

[2035] one or more removable/replaceable memory device(s) 2622; and

[2036] one or more printing device(s) 2624.

[2037] In such more enhanced versions, the display 2618, keypad 2620,memory device 2622 and printer 2624 may be connected to bus 2610, orthey might be connected to CPU 2616 through an I/O port/controllerportion (not shown) of the CPU. Display 2618 may be used to displayinformation from SPU 500, CPU 2616 and/or host 2608. Keypad 2620 may beused to input information to SPU 500, CPU 2616 and/or host 2608. Printer2624 may be used to print information from any/all of these sources.Removable/replaceable memory 2622 may comprise a memory cartridge ormemory medium such as a bulk storage device, for providing additionallong-term or short-term storage. Memory 2622 may be easily removablefrom housing 2602 if desired.

[2038] In one example embodiment, portable appliance 2600 may have theform factor of a “smart card” (although a “smart card” form factor mayprovide certain advantages, housing 2602 may have the same or differentform factor as “conventional” smart cards). Alternatively, such aportable electronic appliance 2600 may, for example, be packaged in aPCMCIA card configuration (or the like) which is currently becomingquite popular on personal computers and is predicted to become commonfor desk-top computing devices and Personal Digital Assistants. Oneadvantageous form factor for the portable electronic appliance housing2602 may be, for example, a Type 1, 2, or 3 PCMCIA card (or otherderivations) having credit card or somewhat larger dimensions. Such aform factor is conveniently portable, and may be insertable into a widearray of computers and consumer appliances, as well as receptacles atcommercial establishments such as retail establishments and banks, andat public communications points, such as telephone or othertelecommunication “booths.”

[2039] Housing 2602 may be insertable into and removable from a port,slot or other receptacle provided by host 2608 so as to be physically(or otherwise operatively) connected to a computer or other electronicappliance. The portable appliance connector 2604 may be configured toallow easy removability so that appliance 2600 may be moved to anothercomputer or other electronic appliance at a different location for aphysical connection or other operative connection with that otherdevice.

[2040] Portable electronic appliance 2600 may provide a valuable andrelatively simple means for a user to move permissions and methodsbetween their (compatible) various electronic appliances 600, such asbetween a notebook computer, a desktop computer and an office computer.It could also be used, for example, to allow a consumer to visit a nextdoor neighbor and allow that neighbor to watch a movie that the consumerhad acquired a license to view, or perhaps to listen to an audio recordon a large capacity optical disk that the consumer had licensed forunlimited plays.

[2041] Portable electronic appliance 2600 may also serve as a “smartcard” for financial and other transactions for users to employ in avariety of other applications such as, for example, commercialapplications. The portable electronic appliance 2600 may, for example,carry permission and/or method information used to authorize (andpossibly record) commercial processes and services.

[2042] An advantage of using the preferred embodiment VDE portableappliance 2600 for financial transactions such as those typicallyperformed by banks and credit card companies is that VDE allowsfinancial clearinghouses (such as VISA, MasterCard, or American Express)to experience significant reductions in operating costs. Theclearinghouse reduction in costs result from the fact that the localmetering and budget management that occurs at the user site through theuse of a VDE electronic appliance 600 such as portable appliance 2600frees the clearinghouse from being involved in every transaction. Incontrast to current requirements, clearinghouses will be able to performtheir functions by periodically updating their records (such as once amonth). Audit and/or budget “roll-ups” may occur during a connectioninitiated to communicate such audit and/or budget information and/orthrough a connection that can occur at periodic or relatively periodicintervals and/or during a credit updating, purchasing, or other portableappliance 2600 transaction.

[2043] Clearinghouse VDE digital distribution transactions would requireonly occasional authorization and/or audit or other administrative“roll-ups” to the central service, rather than far more costlyconnections during each session. Since there would be no requirement forthe maintenance of a credit card purchase “paper trail” (theauthorization and then forwarding of the credit card slip), there couldbe substantial cost reductions for clearinghouses (and, potentially,lower costs to users) due to reduction in communication costs,facilities to handle concurrent processing of information, and paperhandling aspects of transaction processing costs. This use of a portableappliance 2600 would allow credit enforcement to exploit distributedprocessing employing the computing capability in each VDE electronicappliance 600. These credit cost and processing advantages may alsoapply to the use of non-smart card and non-portable VDE electronicappliance 600s.

[2044] Since VDE 100 may be configured as a highly secure commercialenvironment, and since the authentication processes supported by VDEemploy digital signature processes which provide a legal validation thatshould be equivalent to paper documentation and handwritten signatures,the need for portable appliance 2600 to maintain paper trails, even formore costly transactions, is eliminated. Since auditable billing andcontrol mechanisms are built into VDE 100 and automated, they mayreplace traditional electronic interfaces to VISA, Master Card, AMEX andbank debit accounts for digitally distributed other products andservices, and may save substantial operating costs for suchclearinghouses.

[2045] Portable appliance 2600 may, if desired, maintain for a consumera portable electronic history. The portable history can be, for example,moved to an electronic “dock” or other receptacle, in or operativelyconnected to, a computer or other consumer host appliance 2608. Hostappliance 2608 could be, for example, an electronic organizer that hascontrol logic at least in part in the form of a microcomputer and thatstores information in an organized manner, e.g., according to tax and/orother transaction categories (such as type of use or activity). By useof this arrangement, the consumer no longer has to maintain receipts orotherwise manually track transactions but nevertheless can maintain anelectronic, highly secure audit trail of transactions and transactiondescriptions. The transaction descriptions may, for example, securelyinclude the user's digital signature, and optionally, the service orgoods provider's digital signature.

[2046] When a portable appliance 2600 is “docked” to a host 2608 such asa personal computer or other electronic appliance (such as an electronicorganizer), the portable appliance 2600 could communicate interim auditinformation to the host. In one embodiment, this information could beread, directly or indirectly, into a computer or electronic organizermoney and or tax management program (for example, Quicken or MicrosoftMoney and/or Turbo Tax and/or Andrew Tobias' Managing Your Money). Thisautomation of receipt management would be an enormous boon to consumers,since the management and maintenance of receipts is difficult andtime-consuming, receipts are often lost or forgotten, and the detailfrom credit card billings is often wholly inadequate for billing andreimbursement purposes since credit card billings normally don't providesufficient data on the purchased items or significant transactionparameters.

[2047] In one embodiment, the portable appliance 2600 could supportsecure (in this instance encrypted and/or authenticated) two-waycommunications with a retail terminal which may contain a VDE electronicappliance 600 or communicate with a retailer's or third party provider'sVDE electronic appliance 600. During such a secure two-way communicationbetween, for example, each participant's secure VDE subsystem, portableappliance 2600 VDE secure subsystem may provide authentication andappropriate credit or debit card information to the retail terminal VDEsecure subsystem. During the same or different communication session,the terminal could similarly, securely communicate back to the portableappliance 2600 VDE secure subsystem details as to the retail transaction(for example, what was purchased and price, the retail establishment'sdigital signature, the retail terminal's identifier, tax relatedinformation, etc.).

[2048] For example, a host 2608 receptacle for receiving and/orattaching to portable appliance 2600 could be incorporated into oroperatively connected to, a retail or other commercial establishmentterminal. The host terminal 2608 could be operated by either acommercial establishment employee or by the portable appliance 2600holder. It could be used to, for example, input specific keyboard and/orvoice input specific information such as who was taken to dinner, whysomething was purchased, or the category that the information should beattached to. Information could then be automatically “parsed” and routedinto securely maintained (for example, encrypted) appropriate databasemanagement records within portable appliance 2600. Said “parsing” androuting would be securely controlled by VDE secure subsystem processesand could, for example, be based on category information entered in bythe user and/or based on class of establishment and/or type (category)of expenditure information (or other use). Categorization can beprovided by the retail establishment, for example, by securelycommunicating electronic category information as a portion, for example,of electronic receipt information or alternatively by printing a hardcopy receipt using printer 2624. This process of categorization may takeplace in the portable appliance 2600 or, alternatively, it could beperformed by the retail establishment and periodically “rolled-up” andcommunicated to the portable appliance 2600 holder.

[2049] Retail, clearinghouse, or other commercial organizations maymaintain and use by securely communicating to appliance 2600 one or moreof generic classifications of transaction types (for example, asspecified by government taxation rules) that can be used to automate theparsing of information into records and/or for database information“roll-ups” for; and/or in portable appliance 2600 or one or moreassociated VDE nodes. In such instances, host 2608 may comprise anauxiliary terminal, for example, or it could comprise or be incorporateddirectly within a commercial establishments cash registers or otherretail transactions devices. The auxiliary terminal could be menu and/oricon driven, and allow very easy user selection of categorization. Itcould also provide templates, based on transaction type, that couldguide the user through specifying useful or required transactionspecific information (for example, purpose for a business dinner and/orwho attended the dinner). For example, a user might select a businessicon, then select from travel, sales, meals, administration, orpurchasing icons for example, and then might enter in very specificinformation and/or a key word, or other code that might cause thedownloading of a transaction's detail into the portable appliance 2600.This information might also be stored by the commercial establishment,and might also be communicated to the appropriate government and/orbusiness organizations for validation of the reported transactions (thehigh level of security of auditing and communications and authenticationand validation of VDE should be sufficiently trusted so as not torequire the maintenance of a parallel audit history, but parallelmaintenance may be supported, and maintained at least for a limitedperiod of time so as to provide backup information in the event of lossor “failure” of portable appliance 2600 and/or one or more appliance2600 associated VDE installations employed by appliance 2600 forhistorical and/or status information record maintenance). For example,of a retail terminal maintained necessary transaction informationconcerning a transaction involving appliance 2600, it could communicatesuch information to a clearinghouse for archiving (and/or other action)or it could periodically, for example, at the end of a business day,securely communicate such information, for example, in the form of a VDEcontent container object, to a clearinghouse or clearinghouse agent.Such transaction history (and any required VDE related statusinformation such as available credit) can be maintained and ifnecessary, employed to reconstruct the information in a portableappliance 2600 so as to allow a replacement appliance to be provided toan appliance 2600 user or properly reset internal information in datawherein such replacement and/or resetting provides all necessarytransaction and status information.

[2050] In a retail establishment, the auxiliary terminal host 2608 mighttake the form of a portable device presented to the user, for example atthe end of a meal. The user might place his portable appliance 2600 intoa smart card receptacle such as a PCMCIA slot, and then enter whateveradditional information that might appropriately describe the transactionas well as satisfying whatever electronic appliance 600 identificationprocedures) required. The transaction, given the availability ofsufficient credit, would be approved, and transaction relatedinformation would then be communicated back from the auxiliary terminaldirectly into the portable appliance 2600. This would be a highlyconvenient mode of credit usage and record management.

[2051] The portable device auxiliary terminal might be “on-line,” thatis electronically communicating back to a commercial establishmentand/or third party information collection point through the use ofcellular, satellite, radio frequency, or other communications means. Theauxiliary terminal might, after a check by a commercial party inresponse to receipt of certain identification information at thecollection point, communicate back to the auxiliary terminal whether ornot to accept the portable appliance 2600 based on other information,such as a bad credit record or a stolen portable appliance 2600. Such aportable auxiliary terminal would also be very useful at othercommercial establishments, for example at gasoline stations, rental carreturn areas, street and stadium vendors, bars, and other commercialestablishments where efficiency would be optimized by allowing clerksand other personnel to consummate transactions at points other thantraditional cash register locations.

[2052] As mentioned above, portable appliance 2600 may communicate fromtime to time with other electronic appliances 600 such as, for example,a VDE administrator. Communication during a portable appliance 2600usage session may result from internally stored parameters dictatingthat the connection should take place during that current session (ornext or other session) of use of the portable appliance. The portableappliance 600 can carry information concerning a real-time date orwindow of time or duration of time that will, when appropriate, requirethe communication to take place (e.g., perhaps before the transaction orother process which has been contemplated by the user for that sessionor during it or immediately following it). Such a communication can beaccomplished quickly, and could be a secure, VDE two-way communicationduring which information is communicated to a central informationhandler. Certain other information may be communicated to the portableappliance 2600 and/or the computer or other electronic appliance towhich the portable appliance 2600 has been connected. Such communicatedother information can enable or prevent a contemplated process fromproceeding, and/or make the portable appliance 2600, at least in part,unusable or useable. Information communicated to the portable appliance2600 could include one or more modifications to permissions and methods,such as a resetting or increasing of one or more budgets, adding orwithdrawing certain permissions, etc.

[2053] The permissions and/or methods (i.e., budgets carried by theportable appliance 2600 may have been assigned to it in conjunction withan “encumbering” of another, stationary or other portable VDE electronicappliance 600. In one example, a portable appliance 2600 holder or otherVDE electronic appliance 600 and/or VDE electronic appliance 600 usercould act as “guarantor” of the financial aspects of a transactionperformed by another party. The portable appliance 2600 of the holderwould record an “encumbrance,” which may be, during a securecommunication with a clearinghouse, be recorded and maintained by theclearinghouse and/or some other financial services party until all or aportion of debt responsibilities of the other party were paid orotherwise satisfied. Alternatively or in addition, the encumbrance mayalso be maintained within the portable appliance 2600, representing thecontingent obligation of the guarantor. The encumbrance may be, by someformula, included in a determination of the credit available to theguarantor. The credit transfer, acceptance, and,/or record management,and related processes, may be securely maintained by the securityfeatures provided by aspects of the present invention. Portableappliance 600 may be the sole location for said permissions and/ormethods for one or more VDE objects 300, or it may carry budgets forsaid objects that are independent of budgets for said objects that arefound on another, non-portable VDE electronic appliance 600. This mayallow budgets, for example, to be portable, without requiring“encumbering” and budget reconciliation.

[2054] Portable VDE electronic appliance 2600 may carry (as may otherVDE electronic appliance 600s described) information describing credithistory details, summary of authorizations, and usage historyinformation (e.g., audit of some degree of transaction history orrelated summary information such as the use of a certain type/class ofinformation) that allows re-use of certain VDE protected information atno cost or at a reduced cost. Such usage or cost of usage may becontingent, at least in part, on previous use of one or more objects orclass of objects or amount of use, etc., of VDE protected information.

[2055] Portable appliance 2600 may also carry certain information whichmay be used, at least in part, for identification purposes. Thisinformation may be employed in a certain order (e.g. a pattern such as,for example, based on a pseudo-random algorithm) to verify the identityof the carrier of the portable appliance 2600. Such information mayinclude, for example, one's own or a wife's and/or other relativesmaiden names, social security number or numbers of one's own and/orothers, birth dates, birth hospital(s), and other identifyinginformation. It may also or alternatively provide or include one or morepasswords or other information used to identify or otherwiseverify/authenticate an individual's identity, such as voice print andretinal scan information. For example, a portable appliance 2600 can beused as a smart card that carries various permissions and/or methodinformation for authorizations and budgets. This information can bestored securely within portable appliance 2600 in a secure database 610arrangement. When a user attempts to purchase or license an electronicproduct or otherwise use the “smart card” to authorize a process,portable appliance 2600 may query the user for identificationinformation or may initiate an identification process employing scannedor otherwise entered information (such as user fingerprint, retinal orvoice analysis or other techniques that may, for example, employ mappingand/or matching of provided characteristics to information securelystored within the portable appliance 2600). The portable appliance 2600may employ different queries at different times (and/or may present aplurality of queries or requests for scanning or otherwise enteringidentifying information) so as to prevent an individual who has comeinto possession of appropriate information for one or more of the“tests” of identity from being able to successfully employ the portableappliance 2600.

[2056] A portable appliance 600 could also have the ability to transferelectronic currency or credit to another portable appliance 2600 or toanother individual's account, for example, using secure VDEcommunication of relevant content between secure VDE subsystems. Suchtransfer may be accomplished, for example, by telecommunication to, orpresentation at, a bank which can transfer credit and, or currency tothe other account. The transfer could also occur by using two cards atthe same portable appliance 2600 docking station. For example, a credittransaction workstation could include dual PCMCIA slots and appropriatecredit and/or currency transfer application software which allowssecurely debiting one portable appliance 2600 and “crediting” anotherportable appliance (i.e., debiting from one appliance can occur uponissuing a corresponding credit and/or currency to the other appliance).One portable appliance 600, for example, could provide an authenticatedcredit to another user. Employing two “smart card” portable appliance600 would enable the user of the providing of “credit” “smart card” togo through a transaction process in which said user provides properidentification (for example, a password) and identifies a “public key”identifying another “smart card” portable appliance 2600. The otherportable appliance 2600 could use acceptance processes, and provideproper identification for a digital signature (and the credit and/orcurrency sender may also digitally sign a transaction certificate so thesending act may not be repudiated and this certificate may accompany thecredit and/or currency as VDE container content. The transactions mayinvolve, for example, user interface interaction that stipulatesinterest and/or other terms of the transfer. It may employ templates forcommon transaction types where the provider of the credit is queried asto certain parameters describing the agreement between the parties. Thereceiving portable appliance 2600 may iteratively or as a whole bequeried as to the acceptance of the terms. VDE negotiation techniquesdescribed elsewhere in this application may be employed in a smart cardtransfer of electronic credit and/or currency to another VDE smart cardor other VDE installation.

[2057] Such VDE electronic appliance 600/portable appliance 2600 credittransfer features would significantly reduce the overhead cost ofmanaging certain electronic credit and/or currency activities bysignificantly automating these processes through extending thecomputerization of credit control and credit availability that was begunwith credit cards and extended with debit cards. The automation ofcredit extension and/or currency transfer and the associated distributedprocessing advantages described, including the absence of anyrequirement for centralized processing and telecommunications duringeach transaction, truly make credit and/or currency, for many consumersand other electronic currency and/or credit users, an efficient,trusted, and portable commodity.

[2058] The portable appliance 2600 or other VDE electronic appliance600, can, in one embodiment, also automate many tax collectionfunctions. A VDE electronic appliance 600 may, with great security,record financial transactions, identify the nature of the transaction,and identify the required sales or related government transaction taxes,debit the taxes from the users available credit, and securelycommunicate this information to one or more government agencies directlyat some interval (for example monthly), and/or securely transfer thisinformation to, for example, a financial clearinghouse, which would thentransfer one or more secure, encrypted (or unsecure, calculated byclearinghouse, or otherwise computed) information audit packets (e.g.,VDE content containers and employing secure VDE communicationtechniques) to the one or more appropriate, participating governmentagencies. The overall integrity and security of VDE 100 could ensure, ina coherent and centralized manner, that electronic reporting of taxrelated information (derived from one or more electronic commerceactivities) would be valid and comprehensive. It could also act as avalidating source of information on the transfer of sales tax collection(e.g., if, for example, said finds are transferred directly to thegovernment by a commercial operation and/or transferred in a manner suchthat reported tax related information cannot be tampered with by otherparties in a VDE pathway of tax information handling). A governmentagency could select transactions randomly, or some subset or all of thereported transactions for a given commercial operation can be selected.This could be used to ensure that the commercial operation is actuallypaying to the government all appropriate collected funds required fortaxes, and can also ensure that end-users are charged appropriate taxesfor their transactions (including receipt of interest from bankaccounts, investments, gifts, etc.

[2059] Portable appliance 2600 financial and tax processes could involvetemplate mechanisms described elsewhere herein. While such an electroniccredit and/or currency management capability would be particularlyinteresting if managed at least in part, through the use of a portableappliance 2600, credit and/or currency transfer and similar featureswould also be applicable for non-portable VDE electronic appliance 600'sconnected to or installed within a computer or other electronic device.

[2060] User Notification Exception Interface (“Pop Up”) 686

[2061] As described above, the User Modification Exception Interface 686may be a set of user interface programs for handling common VDEfunctions. These applications may be forms of VDE templates and aredesigned based upon certain assumptions regarding important options,specifically, appropriate to a certain VDE user model and importantmessages that must be reported given certain events A primary functionof the “pop-up” user interface 686 is to provide a simple, consistentuser interface to, for example, report metering events and exceptions(e.g., any condition for which automatic processing is either impossibleor arguably undesirable) to the user, to enable the user to configurecertain aspects of the operation of her electronic appliance 600 and,when appropriate, to allow the user to interactively control whether toproceed with certain transaction processes. If an object contains anexception handling method, that method will control how the “pop-up”user interface 686 handles specific classes of exceptions.

[2062] The “pop-user” interface 686 normally enables handling of tasksnot dedicated to specific objects 300, such as for example:

[2063] Logging onto an electronic appliance 600 and/or entering into aVDE related activity or class of activities,

[2064] Configuring an electronic appliance 600 for a registered user,and/or generally for the installation, with regard to user preferences,and automatic handling of certain types of exceptions,

[2065] Where appropriate, user selecting of meters for use with specificproperties, and

[2066] Providing an interface for communications with other electronicappliances 600, including requesting and/or for purchasing or leasingcontent from distributors, requesting clearinghouse credit and/orbudgets from a clearinghouse, sending and/or receiving information toand/or from other electronic appliances, and so on.

[2067]FIG. 72A shows an example of a common “logon” VDE electronicappliance 600 function that may use user interface 686. “Log-on” can bedone by entering a user name, account name, and/or password. As shown inthe provided example, a configuration option provided by the “pop-up”user interface 686 dialog can be “Login at Setup”, which, if selected,will initiate a VDE Login procedure automatically every time the user'selectronic appliance 600 is turned on or reset. Similarly, the “pop-up”user interface 686 could provide an interface option called “Login atType” which, if selected, will initiate a procedure automatically everytime, for example, a certain type of object or specific content typeapplication is opened such as a file in a certain directory, a computerapplication or file with a certain identifying extension, or the like.

[2068]FIG. 72B shows an example of a “pop-up” user interface 686 dialogthat is activated when an action by the user has been “trapped,” in thiscase to warn the user about the amount of expense that will be incurredby the user's action, as well as to alert the user about the object 300which has been requested and what that particular object will cost touse. In this example, the interface dialog provides a button allowingthe user to request further detailed information about the object,including full text descriptions, a list of associated files, andperhaps a history of past usage of the object including any residualrights to use the object or associated discounts.

[2069] The “Cancel” button 2660 in FIG. 72B cancels the user's trappedrequest. “Cancel” is the default in this example for this dialog and canbe activated, for example, by the return and enter keys on the userskeyboard 612, by a “mouse click” on that button, by voice command, orother command mechanisms. The “Approve button” 2662, which must beexplicitly selected by a mouse click or other command procedure, allowsthe user to approve the expense and proceed. The “More options” control2664 expands the dialog to another level of detail which providesfurther options, an example of which is shown in FIG. 72C.

[2070]FIG. 72C shows a secondary dialog that is presented to the user bythe “pop-up” user interface 686 when the “More options” button 2664 inFIG. 72B is selected by the user. As shown, this dialog includesnumerous buttons for obtaining further information and performingvarious tasks.

[2071] In this particular example, the user is permitted to set “limits”such as, for example, the session dollar limit amount (field 2666), atotal transaction dollar limit amount (field 2668), a time limit (inminutes) (field 2670), and a “unit limit” (in number of units such asparagraphs, pages, etc.) (field 2672). Once the user has made herselections, she may “click on” the OKAY button (2674) to confirm thelimit selections and cause them to take effect.

[2072] Thus, pop-up user interface dialogues can be provided to specifyuser preferences, such as setting limits on budgets and/or other aspectsof object content usage during any one session or over a certainduration of time or until a certain point in time. Dialogs can also beprovided for selecting object related usage options such as selectingmeters and budgets to be used with one or more objects. Selection ofoptions may be applied to types (that is classes) of objects byassociating the instruction with one or more identifying parametersrelated to the desired one or more types. User specified configurationinformation can set default values to be used in various situations, andcan be used to limit the number or type of occasions on which the user'suse of an object is interrupted by a “pop-up” interface 686 dialog. Forexample, the user might specify that a user request for VDE protectedcontent should be automatically processed without interruption(resulting from an exceptions action) if the requested processing ofinformation will not cost more than $25.00 and if the total charge forthe entire current session (and/or day and/or week, etc.) is not greaterthan $200.00 and if the total outstanding and unpaid charge for usehasn't exceeded $2500.00.

[2073] Pop-up user interface dialogs may also be used to notify the userabout significant conditions and events. For example, interface 686 maybe used to:

[2074] remind the user to send audit information to a clearinghouse,

[2075] inform a user that a budget value is low and needs replenishing,

[2076] remind the user to back up secure database 610, and

[2077] inform the user about expirations of PERCs or other dates/timesevents.

[2078] Other important “pop-up” user interface 686 functions includedialogs which enable flexible browsing through libraries of propertiesor objects available for licensing or purchase, either from locallystored VDE protected objects and/or from one or more various, remotelylocated content providers. Such function may be provided either whilethe user's computer is connected to a remote distributor's orclearinghouse's electronic appliance 600, or by activating an electronicconnection to a remote source after a choice (such as a property, aresource location, or a class of objects or resources is selected). Abrowsing interface can allow this electronic connection to be madeautomatically upon a user selection of an item, or the connection itselfcan be explicitly activated by the user. See FIG. 72D for an example ofsuch a “browsing” dialog.

[2079] Smart Objects

[2080] VDE 100 extends its control capabilities and features to“intelligent agents.” Generally, an “intelligent agent” can act as anemissary to allow a process that dispatches it to achieve a result theoriginating process specifies. Intelligent agents that are capable ofacting in the absence of their dispatch process are particularly usefulto allow the dispatching process to access, through its agent, theresources of a remote electronic appliance. In such a scenario, thedispatch process may create an agent (e.g., a computer program and orcontrol information associated with a computer program) specifying aparticular desired task(s), and dispatch the agent to the remote system.Upon reaching the remote system, the “agent” may perform its assignedtask(s) using the remote system's resources. This allows the dispatchprocess to, in effect, extend its capabilities to remote systems whereit is not present.

[2081] Using an “agent” in this manner increases flexibility. Thedispatching process can specify, through its agent, a particular desiredtask(s) that may not exist or be available on the remote system. Usingsuch an agent also provides added trustedness; the dispatch process mayonly need to “trust” its agent, not the entire remote system. Agentshave additional advantages.

[2082] Software agents require a high level of control andaccountability to be effective, safe and useful. Agents in the form ofcomputer viruses have had devastating effects worldwide. Therefore, asystem that allows an agent to access it should be able to control it orotherwise prevent the agent from damaging important resources. Inaddition, systems allowing themselves to be accessed by an agent shouldsufficiently trust the agent and/or provide mechanisms capable ofholding the true dispatcher of the agent responsible for the agent'sactivities. Similarly, the dispatching process should be able toadequately limit and/or control the authority of the agents itdispatches or else it might become responsible for unforeseen activitiesby the agent (e.g., the agent might run up a huge bill in the course offollowing imprecise instructions it was given by the process thatdispatched it).

[2083] These significant problems in using software agents have not beadequately addressed in the past. The open, flexible control structuresprovided by VDE 100 addresses these problems by providing the desiredcontrol and accountability for software agents (e.g., agent objects).For example, VDE 100 positively controls content access and usage,provides guarantee of payment for content used, and enforces budgetlimits for accessed content. These control capabilities are well suitedto controlling the activities of a dispatched agent by both the processthat dispatches the agent and the resource accessed by the dispatchedagent.

[2084] One aspect of the preferred embodiment provided by the presentinvention provides a “smart object” containing an agent. Generally, a“smart object” may be a VDE object 300 that contains some type(s) ofsoftware programs (“agents”) for use with VDE control information at aVDE electronic appliance 600. A basic “smart object” may comprise a VDEobject 300 that, for example, contains (physically and/or virtually):

[2085] a software agent, and

[2086] at least one rule and/or control associated with the softwareagent that governs the agent's operation.

[2087] Although this basic structure is sufficient to define a “smartobject,” FIG. 73 shows a combination of containers and controlinformation that provides one example of a particularly advantageoussmart object structure for securely managing and controlling theoperation of software agents.

[2088] As shown in FIG. 73, a smart object 3000 may be constructed of acontainer 300, within which is embedded one or more further containers(300 z, 300 y, etc.). Container 300 may further contain rules andcontrol information for accessing and using these embedded containers300 z, 300 y, etc. Container 300 z embedded in container 300 is whatmakes the object 3000 a “smart object.” It contains an “agent” that ismanaged and controlled by VDE 100.

[2089] The rules and control information 806 f associated with container300 z govern the circumstances under which the agent may be released andexecuted at a remote VDE site, including any limitations on executionbased on the cost of execution for example. This rule and controlinformation may be specified entirely in container 300 z, and or may bedelivered as part of container 300, as part of another container (eitherwithin container 300 or a separately deliverable container), and/or maybe already present at the remote VDE site.

[2090] The second container 300 y is optional, and contains content thatdescribes the locations at which the agent stored in container 300 z maybe executed. Container 300 y may also contain rules and controlinformation 806 e that describe the manner in which the contents ofcontainer 300 y may be used or altered. This rule and controlinformation 806 e and/or further rules 300 y(1) also contained withincontainer 300 y may describe searching and routing mechanisms that maybe used to direct the smart object 3000 to a desired remote informationresource. Container 300 y may contain and/or reference rules and controlinformation 300 y(1) that specify the manner in which searching androuting information use and any changes may be paid for.

[2091] Container 300 x is an optional content container that isinitially “empty” when the smart object 3000 is dispatched to a remotesite. It contains rules and control information 300 x(1) for storing thecontent that is retrieved by the execution of the agent contained incontainer 300 z. Container 300 x may also contain limits on the value ofcontent that is stored in the retrieval container so as to limit theamount of content that is retrieved.

[2092] Other containers in the container 300 may include administrativeobjects that contain audit and billing trails that describe the actionsof the agent in container 300 z and any charges incurred for executingan agent at a remote VDE node. The exact structure of smart object 3000is dependent upon the type of agent that is being controlled, theresources it will need for execution, and the types of information beingretrieved.

[2093] The smart object 3000 in the example shown in FIG. 73 may be usedto control and manage the operation of an agent in VDE 100. Thefollowing detailed explanation of an example smart object transactionshown in FIG. 74 may provide a helpful, but non-limiting illustration.In this particular example, assume a user is going to create a smartobject 3000 that performs a library search using the “Very Fast andEfficient” software agent to search for books written about some subjectof interest (e.g., “fire flies”). The search engine is designed toreturn a list of books to the user. The search engine in this examplemay spend no more than $10.00 to find the appropriate books, may spendno more than $3.00 in library access or communications charges to get tothe library, and may retrieve no more than $15.00 in information. Allinformation relating to the search or use is to be returned to the userand the user will permit no information pertaining to the user or theagent to be released to a third party.

[2094] In this example, a dispatching VDE electronic appliance 3010constructs a smart object 3000 like the one shown in FIG. 73. The ruleset in 806 a is specified as a control set that contains the followingelements:

[2095] 1. a smart_agent_execution event that specifies the smart agentis stored in embedded container 300 z and has rules controlling itsexecution specified in that container;

[2096] 2. a smart_agent_use event that specifies the smart agent willoperate using information and parameters stored in container 300;

[2097] 3. a routing_use event that specifies the information routinginformation is stored in container 300 y and has rules controlling thisinformation stored in that container;

[2098] 4. an information_write event that specifies information writtenwill be stored in container 300 y, 300 x, or 300 w depending on its type(routing, retrieved, or administrative), and that these containers haveindependent rules that control how information is written into them.

[2099] The rule set in control set 806 b contains rules that specify therights desired by this smart object 3000. Specifically, this control setspecifies that the software agent desires:

[2100] 1. A right to use the “agent execution” service on the remote VDEsite. Specific billing and charge information for this right is carriedin container 300 z.

[2101] 2. A right to use the “software description list” service on theremote VDE site. Specific billing and charge information for this forthis right is carried in container 300 y.

[2102] 3. A right to use an “information locator service” on a remoteVDE site.

[2103] 4. A right to have information returned to the user withoutcharge (charges to be incurred on release of information and paymentwill be by a VISA budget)

[2104] 5. A right to have all audit information returned such that it isreadable only by the sender.

[2105] The rule set in control set 806 c specifies that container 300 wspecifies the handling of all events related to its use. The rule set incontrol set 806 d specifies that container 300 x specifies the handlingof all events related to its use. The rule set in control set 806 especifies that container 300 y specifies the handling of all eventsrelated to its use. The rule set in control set 806 f specifies thatcontainer 300 z specifies the handling of all events related to its use.

[2106] Container 300 z is specified as containing the “Very Fast andEfficient” agent content, which is associated with the following rulesset:

[2107] 1. A use event that specifies a meter and VISA budget that limitsthe execution to $10.00 charged against the owner's VISA card. Audits ofusage are required and will be stored in object 300 w under controlinformation specified in that object.

[2108] After container 300 z and its set are specified, they areconstructed and embedded in the smart object container 300.

[2109] Container 300 y is specified as a content object with two typesof content. Content type A is routing information and is read/write innature. Content type A is associated with a rules set that specifies:

[2110] 1. A use event that specifies no operation for the release of thecontent. This has the effect of not charging for the use of the content.

[2111] 2. A write event that specifies a meter and a VISA budget thatlimits the value of writing to $3.00. The billing method used by thewrite is left unspecified and will be specified by the control methodthat uses this rule.

[2112] 3. Audits of usage are required and will be stored in object 300w under control information specified in that object.

[2113] Content type B is information that is used by the software agentto specify parameters for the agent. This content is specified as thestring “fire fly” or “fire flies”. Content type B is associated with thefollowing rule set:

[2114] 1. A use event that specifies that the use may only be by thesoftware agent or a routing agent. The software agent has read onlypermission, the routing agent has read/write access to the information.There are no charges associated with using the information, but twometers; one by read and one by write are kept to track use of theinformation by various steps in the process.

[2115] 2. Audits of usage are required and will be stored in object 300w under control information specified in that object.

[2116] After container 300 y and its control sets are specified, theyare constructed and embedded in the smart object container 300.

[2117] Container 300 x is specified as a content object that is empty ofcontent. It contains a control set that contains the following rules:

[2118] 1. A write_without_billing event that specifies a meter and ageneral budget that limits the value of writing to $15.00.

[2119] 2. Audits of usage are required and will be stored in object 300w under control information specified in that object.

[2120] 3. An empty use control set that may be filled in by the owner ofthe information using predefined methods (method options).

[2121] After container 300 x and its control sets are specified, theyare constructed and embedded in the smart object container 300.

[2122] Container 300 w is specified as an empty administrative objectwith a control set that contains the following rules:

[2123] 1. A use event that specifies that the information contained inthe administrative object may only be released to the creator of smartobject container 300.

[2124] 2. No other rules may be attached to the administrative contentin container 300 w.

[2125] After container 300 w and its control sets are specified, theyare constructed and embedded in the smart object container 300.

[2126] At this point, the smart object has been constructed and is readyto be dispatched to a remote VDE site. The smart object is sent to aremote VDE site (e.g., using electronic mail or another transportmechanism) that contains an information locator service 3012 via path3014. The smart object is registered at the remote site 3012 for the“item locator service.” The control set in container related to “itemlocator service” is selected and the rules contained within it activatedat the remote site 3012. The remote site 3012 then reads the contents ofcontainer 300 y under the control of rule set 806 f and 300 y(1), andpermits writes of a list of location information into container 300 ypursuant to these rules. The item locator service writes a list of threeitems into the smart object, and then “deregisters” the smart object(now containing the location information) and sends it to a site 3016specified in the list written to the smart object via path 3018. In thisexample, the user may have specified electronic mail for transport and alist of remote sites that may have the desired information is stored asa forwarding list.

[2127] The smart object 3000, upon arriving at the second remote site3016, is registered with that second site. The site 3016 provides agentexecution and software description list services compatible with VDE asa service to smart objects. It publishes these services and specifiesthat it requires $10.00 to start the agent and $20/piece for allinformation returned. The registration process compares the publishedservice information against the rules stored within the object anddetermines that an acceptable overlap does not exist. Audit informationfor all these activities is written to the administrative object 300 w.The registration process then fails (the object is not registered), andthe smart object is forwarded by site 3016 to the next VDE site 3020 inthe list via path 3022.

[2128] The smart object 3000, upon arriving at the third remote site3020, is registered with that site. The site 3020 provides agentexecution and software description list services compatible with VDE asa service to smart objects. It publishes these services and specifiesthat it requires $1.00 to start the agent and $0.50/piece for allinformation returned. The registration process compares the publishedservice information against the rules stored within the object anddetermines that an acceptable overlap exists. The registration processcreates a URT that specifies the agreed upon control information. ThisURT is used in conjunction with the other control information to executethe software agent under VDE control.

[2129] The agent software starts and reads its parameters out ofcontainer 300 y. It then starts searching the database and obtains 253“hits” in the database. The list of hits is written to container 300 xalong with a completed control set that specifies the granularity ofeach item and that each item costs $0.50. Upon completion of the search,the budget for use of the service is incremented by $1.00 to reflect theuse charge for the service. Audit information for all these activitiesis written to the administrative object 300 w.

[2130] The remote site 3020 returns the now “full” smart object 3000back to the original sender (the user) at their VDE node 3010 via path3024. Upon arrival, the smart object 3000 is registered and the databaserecords are available. The control information specified in container300 x is now a mix of the original control information and the controlinformation specified by the service regarding remote release of theirinformation. The user then extracts 20 records from the smart object3000 and has $10.00 charged to her VISA budget at the time ofextraction.

[2131] In the above smart agent VDE examples, a certain organization ofsmart object 3000 and its constituent containers is described. Otherorganizations of VDE and smart object related control information andparameter data may be created and may be used for the same purposes asthose ascribed to object 3000 in the above example.

[2132] Negotiation and Electronic Contracts

[2133] An electronic contract is an electronic form of an agreementincluding rights, restrictions, and obligations of the parties to theagreement. In many cases, electronic agreements may surround the use ofdigitally provided content; for example, a license to view a digitallydistributed movie. It is not required, however, that an electronicagreement be conditioned on the presence or use of electronic content byone or more parties to the agreement. In its simplest form, anelectronic agreement contains a right and a control that governs howthat right is used.

[2134] Electronic agreements, like traditional agreements, may benegotiated between their parties (terms and conditions submitted by oneor more parties may simply be accepted (cohesion contract) by one ormore other parties and/or such other parties may have the right toselect certain of such terms and conditions (while others may berequired)). Negotiation is defined in the dictionary as “the act ofbringing together by mutual agreement.” The preferred embodimentprovides electronic negotiation processes by which one or more rightsand associated controls can be established through electronic automatednegotiation of terms. Negotiations normally require a precisespecification of rights and controls associated with those rights. PERCand URT structures provide a mechanism that may be used to provideprecise electronic representations of rights and the controls associatedwith those rights. VDE thus provides a “vocabulary” and mechanism bywhich users and creators may specify their desires. Automated processesmass interpret these desires and negotiate to reach a common middleground based on these desires. The results of said negotiation may beconcisely described in a structure that may be used to control andenforce the results of the electronic agreement. VDE further enablesthis process by providing a secure execution space in which thenegotiation process(es) are assured of integrity and confidentiality intheir operation. The negotiation process(es) may also be executed insuch a manner that inhibits external tampering with the negotiation.

[2135] A final desirable feature of agreements in general (andelectronic representations of agreements in particular) is that they beaccurately recorded in a non-repudiatable form. In traditional terms,this involves creating a paper document (a contract) that describes therights, restrictions, and obligations of all parties involved. Thisdocument is read and then signed by all parties as being an accuraterepresentation of the agreement. Electronic agreements, by their nature,may not be initially rendered in paper. VDE enables such agreements tobe accurately electronically described and then electronically signed toprevent repudiation. In addition, the preferred embodiment provides amechanism by which human-readable descriptions of terms of theelectronic contract can be provided.

[2136] VDE provides a concise mechanism for specifying control sets thatare VDE site interpretable. Machine interpretable mechanisms are oftennot human readable. VDE often operates the negotiation process on behalfof at least one human user. It is thus desirable that the negotiation beexpressible in “human readable form.” VDE data structures for objects,methods, and load modules all have provisions to specify one or moreDTDs within their structures. These DTDs may be stored as part of theitem or they may be stored independently. The DTD describes one or moredata elements (MDE, UDE, or other related data elements) that maycontain a natural language description of the function of that item.These natural language descriptions provide a language independent,human readable description for each item. Collections of items (forexample, a BUDGET method) can be associated with natural language textthat describes its function and forms a term of an electronicallyspecified and enforceable contract. Collections of terms (a control set)define a contract associated with a specific right. VDE thus permits theelectronic specification, negotiation, and enforcement of electroniccontracts that humans can understand and adhere to.

[2137] VDE 100 enables the negotiation and enforcement of electroniccontracts in several ways:

[2138] it enables a concise specification of rights and controlinformation that permit a common vocabulary and procedure fornegotiation,

[2139] it provides a secure processing environment within which tonegotiate,

[2140] it provides a distributed environment within which rights andcontrol specifications may be securely distributed,

[2141] it provides a secure processing environment in which negotiatedcontracts may be electronically rendered and signed by the processesthat negotiate them, and

[2142] it provides a mechanism that securely enforces a negotiatedelectronic contract.

[2143] Types of Negotiations

[2144] A simple form of a negotiation is a demand by one party to forman “adhesion” contract. There are few, if any, options that may bechosen by the other party in the negotiation. The recipient of thedemand has a simple option; she may accept or reject the terms andconditions (control information) in the demand. If she accepts theconditions, she is granted rights subject to the specified controlinformation. If she rejects the conditions, she is not granted therights. PERC and URT structures may support negotiation by demand; aPERC or control set from a PERC may be presented as a demand, and therecipient may accept or reject the demand (selecting any permittedmethod options if they are presented).

[2145] A common example of this type of negotiation today is thepurchase of software under the terms of a “shrink-wrap license.” Manywidely publicized electronic distribution schemes use this type ofnegotiation. CompuServe is an example of an on-line service thatoperates in the same manner. The choice is simple: either pay thespecified charge or don't use the service or software. VDE supports thistype of negotiation with its capability to provide PERCs and URTs thatdescribe rights and control information, and by permitting a contentowner to provide a REGISTER method that allows a user to select from aset of predefined method options. In this scenario, the REGISTER methodmay contain a component that is a simplified negotiation process.

[2146] A more complex form of a negotiation is analogous to “haggling.”In this scenario, most of the terms and conditions are fixed, but one ormore terms (e.g., price or payment terms) are not. For these terms,there are options, limits, and elements that may be negotiated over. AVDE electronic negotiation between two parties may be used to resolvethe desired, permitted, and optional terms. The result of the electronicnegotiation may be a finalized set of rules and control information thatspecify a completed electronic contract. A simple example is thescenario for purchasing software described above adding the ability ofthe purchaser to select a method of payment (VISA, Mastercard, orAmerican Express). A more complex example is a scenario for purchasinginformation in which the price paid depends on the amount of informationabout the user that is returned along with a usage audit trail. In thissecond example, the right to use the content may be associated with twocontrol sets. One control set may describe a fixed (“higher”) price forusing the content. Another control set may describe a fixed (“lower”)price for using the content with additional control information andfield specifications requiring collection and return the user's personalinformation. In both of these cases, the optional and permitted fieldsand control sets in a PERC may describe the options that may be selectedas part of the negotiation. To perform the negotiation, one party maypropose a control set containing specific fields, control information,and limits as specified by a PERC; the other party may pick and acceptfrom the control sets proposed, reject them, or propose alternatecontrol sets that might be used. The negotiation process may use thepermitted, required, and optional designations in the PERC to determinean acceptable range of parameters for the final rule set. Once anagreement is reached, the negotiation process may create a new PERCand/or URT that describes the result of the negotiation. The resultingPERCs and/or URTs may be “signed” (e.g., using digital signatures) byall of the negotiation processes involved in the negotiation to preventrepudiation of the agreement at a later date.

[2147] Additional examples of negotiated elements are: electronic cash,purchase orders, purchase certificates (gift certificates, coupons),bidding and specifications, budget “rollbacks” and reconciliation,currency exchange rates, stock purchasing, and billing rates.

[2148] A set of PERCs that might be used to support the second exampledescribed above is presented in FIGS. 75A (PERC sent by the contentowner), 75B (PERC created by user to represent their selections andrights), and 75C (PERC for controlling the negotiation process). ThesePERCs might be used in conjunction with any of the negotiationprocess(es) and protocols described later in this section.

[2149]FIG. 75A shows an example of a PERC 3100 that might be created bya content provider to describe their rights options. In this example,the PERC contains information regarding a single USE right. Twoalternate control sets 3102 a, 3102 b are presented for this right inthe example. Control set 3102 a permits the use of the content withoutpassing back information about the user, and another control set 3102 bpermits the use of the content and collects “response card” typeinformation from the user. Both control sets 3102 a, 3102 b may use acommon set of methods for most of the control information. This commoncontrol information is represented by a CSR 3104 and CS0 3106.

[2150] Control set 3102 a in this PERC 3100 describes a mechanism bywhich the user may obtain the content without providing any informationabout its user to the content provider. This control set 3102 aspecifies a well-known vending control method and set of requiredmethods and method options. Specifically, in this example, control set3102 a defines a BUDGET method 3108 (e.g., one of VISA, Mastercard, orAmerican Express) and it defines a BILLING method 3110 that specifies acharge (e.g., a one-time charge of $100.00).

[2151] Control set 3102 b in this PERC 3100 describes another mechanismby which the user may obtain the content. In this example, the controlset 3102 b specifies a different vending control method and a set ofrequired methods and method options. This second control set 3102 bspecifies a BUDGET method 3112 (e.g., one of VISA, Mastercard, orAmerican Express), a BILLING method 3116 that specifies a charge (e.g.,a lesser one-time charge such as $25.00) and an AUDIT method 3114 thatspecifies a set of desired and required fields. The required and desiredfield specification 3116 may take the form of a DTD specification, inwhich, for example, the field names are listed.

[2152] The content creator may “prefer” one of the two control sets(e.g., control set 2) over the other one. If so, the “preferred” controlset may be “offered” first in the negotiation process, and withdrawn infavor of the “non-preferred” control set if the other party to thenegotiation “rejects” the “preferred” control set.

[2153] In this example, these two control sets 3102 a, 3102 b may sharea common BUDGET method specification. The BUDGET method specificationmay be included in the CSR 3104 or CS0 3106 control sets if desired.Selecting control set 3102 a (use with no information passback) causes aunique component assembly to be assembled as specified by the PERC 3100.Specifically, in this example it selects the “Vending” CONTROL method3118, the BILLING method 3110 for a $100 fixed charge, and the rest ofthe control information specified by CSR 3104 and CS0 3106. It alsorequires the user to specify her choice of acceptable BUDGET method(e.g., from the list including VISA, Mastercard, and American Express).Selecting control set 3102 b assembles a different component assemblyusing the “Vending with ‘response card’” CONTROL method 3120, theBILLING method 3116 (e.g., for a $25 fixed charge), an AUDIT method 3114that requires the fields listed in the Required Fields DTD 3116. Theprocess may also select as many of the fields listed in the DesiredFields DTD 3116 as are made available to it. The rest of the controlinformation is specified by CSR 3104 and CS0 3106. The selection ofcontrol set 3102 b also forces the user to specify their choice ofacceptable BUDGET methods (e.g., from the list including VISA,Mastercard, and American Express).

[2154]FIG. 75B shows an example of a control set 3125 that might be usedby a user to specify her desires and requirements in a negotiationprocess. This control set has a USE rights section 3127 that contains anaggregated CSR budget specification 3129 and two optional control sets3131 a, 3131 b for use of the content. Control set 3131 a requires theuse of a specific CONTROL method 3133 and AUDIT method 3135. Thespecified AUDIT method 3135 is parameterized with a list of fields 3137that may be released in the audit trail. Control set 3131 a alsospecifies a BILLING method 3139 that can cost no more than a certainamount (e.g.. $30.00). Control set 3131 b in this example describes aspecific CONTROL method 3141 and may reference a BILLING method 3143that can cost no more than a certain amount (e.g., $150.00) if thisoption is selected.

[2155]FIG. 75E shows a more high-level view of an electronic contract3200 formed as a “result” of a negotiation process as described above.Electronic contract 3200 may include multiple clauses 3202 and multipledigital signatures 3204. Each clause 3202 may comprise a PERC/URT suchas item 3160 described above and shown in FIG. 75D. Each “clause” 3202of electronic contract 3200 thus corresponds to a component assembly 690that may be assembled and executed by a VDE electronic appliance 600.Just as in normal contracts, there may be as many contract clauses 3202within electronic contract 3200 as is necessary to embody the“agreement” between the “parties.” Each of clauses 3202 may have beenelectronically negotiated and may thus embody a part of the “agreement”(e.g., a “compromise”) between the parties. Electronic contract 3200 is“self-executing” in the sense that it may be literally executed by amachine, i.e., a VDE electronic appliance 600 that assembles componentassemblies 690 as specified by various electronic clauses 3202.Electronic contract 3200 may be automatically “enforced” using the sameVDE mechanisms discussed above that are used in conjunction with anycomponent assembly 690. For example, assuming that a clause 3202(2)corresponds to a payment or BILLING condition or term, its correspondingcomponent assembly 690 when assembled by a user's VDE electronicappliance 600 may automatically determine whether conditions are rightfor payment and, when they are, automatically access an appropriatepayment mechanism (e.g., a virtual “credit card” object for the user) toarrange that payment to be made. As another example, assuming thatelectronic contract clause N 3202(N) corresponds to a user's obligationto provide auditing information to a particular VDE participant,electronic contract 3200 will cause VDE electronic appliance 600 toassemble a corresponding component assembly 690 that may, for example,access the appropriate audit trails within secure database 610 andprovide them in an administrative object to the correct participant.FIG. 75F shows that clause 3202(N) may, for example, specify a componentassembly 690 that arranges for multiple steps in a transaction 3206 tooccur. Some of these steps (e.g., step 3208(4), 3208(5)) may beconditional on a test (e.g., 3208(3)) such as, for example, whethercontent usage has exceeded a certain amount, whether a certain timeperiod has expired, whether a certain calendar date has been reached,etc.

[2156] Digital signatures 3204 shown in the FIG. 75E electronic contract3200 may comprise, for example, conventional digital signatures usingpublic key techniques as described above. Some electronic contracts 3200may not bear any digital signatures 3204. However, it may be desirableto require the electronic appliance 600 of the user who is a party tothe electronic contract 3200 to digitally “sign” the electronic contractso that the user cannot later repudiate the contract, for evidentiarypurposes, etc. Multiple parties to the same contract may each digitally“sign” the same electronic contract 3200 similarly to the way multipleparties to a contract memorialized in a written instrument use an inkpen to sign the instrument.

[2157] Although each of the clauses 3202 of electronic contract 3200 mayultimately correspond to a collection of data and code that may beexecuted by a PPE 650, there may in some instances be a need forrendering a human readable version of the electronic contract. This needcan be accommodated by, as mentioned above, providing text within one ormore DTDs associated with the component assembly or assemblies 690 usedto “self-execute” the contract. Such text might, for example, describefrom a functional point of view what the corresponding electroniccontract clause 3202 means or involves, and/or might describe in legallyenforceable terms what the legal obligation under the contract is orrepresents. “Templates” (described elsewhere herein) might be used tosupply such text from a text library. An expert system and/or artificialintelligence capability might be used to impose syntax rules that binddifferent textual elements together into a coherent, humanly readablecontract document. Such text could, if necessary, be reviewed andmodified by a “human” attorney in order customize it for the particularagreement between the parties and/or to add further legal obligationsaugmenting the “self-executing” electronic obligations embodied withinand enforced by the associated component assemblies 690 executing on aVDE electronic appliance 600. Such text could be displayed automaticallyor on demand upon execution of the electronic contract, or it could beused to generate a printed humanly-readable version of the contract atany time. Such a document version of the electronic contract 3200 wouldnot need to be signed in ink by the parties to the agreement (unlessdesired) in view of the fact that the digital signatures 3204 wouldprovide a sufficiently secure and trusted evidentiary basis for provingthe parties' mutual assent to all the terms and conditions within thecontract.

[2158] In the preferred embodiment, the negotiation process executeswithin a PPE 650 under the direction of a further PERC that specifiesthe process. FIG. 75C shows an example of a PERC 3150 that specifies anegotiation process. The PERC 3150 contains a single right 3152 fornegotiation, with two permitted control sets 3154 a, 3154 b describedfor that right. The first control set 3154 a may be used for a “trustednegotiation”; it references the desired negotiation CONTROL method(“Negotiate”) 3156 and references (in fields 3157 a, 3157 b) two UDEsthat this CONTROL method will use. These UDEs may be, for example, thePERCs 3100, 3125 shown in FIGS. 75A and 75B. The second control set 3154b may be used by “multiple negotiation” processes to manage thenegotiation, and may provide two negotiation methods: “Negotiate1,” and“Negotiate2”. Both negotiation processes may be described as requiredmethods (“Negotiate1” and “Negotiate2”) 3156, 3158 that take respectivePERCs 3100, 3125 as their inputs. The CONTROL method 3158 for thiscontrol set in this example may specify the name of a service that thetwo negotiation processes will use to communicate with each other, andmay also manage the creation of the URT resulting from the negotiation.

[2159] When executed, the negotiation process(es) specified by the PERC3150 shown in FIG. 75C may be provided with the PERCs 3100, 3125 asinput that will be used as the basis for negotiation. In this example,the choice of negotiation process type (trusted or multiple) may be madeby the executing VDE node. The PERC 3150 shown in FIG. 75C might be, forexample, created by a REGISTER method in response to a register requestfrom a user. The process specified by this PERC 3150 may then be used bya REGISTER method to initiate negotiation of the terms of an electroniccontract.

[2160] During this example negotiation process, the PERCs 3100, 3125shown in FIGS. 75A and 75B act as input data structures that arecompared by a component assembly created based on PERC 3150 shown inFIG. 35C. The component assembly specified by the control sets may beassembled and compared, starting with required “terms,” and progressingto preferred/desired “terms” and then moving on to permitted “terms,” asthe negotiation continues. Method option selections are made using thedesired method and method options specified in the PERCs 3100, 3125. Inthis example, a control set for the PERC 3100 shown in FIG. 75A may becompared against the PERC 3125 shown in FIG. 75B. If there is a “match,”the negotiation is successfully concluded and “results” are generated.

[2161] In this embodiment, the results of such negotiation willgenerally be written as a URT and “signed” by the negotiationprocess(es) to indicate that an agreement has been reached. Theseelectronic signatures provide the means to show that a (virtual)“meeting of minds” was reached (one of the traditional legalpreconditions for a contract to exist). An example of the URT 3160 thatwould have been created by the above example is shown in FIG. 75D.

[2162] This URT 3160 (which may itself be a PERC 808) includes a controlset 3162 that reflects the “terms” that were “agreed upon” in thenegotiation. In this example, the “agreed upon” terms must “match” termsrequired by input PERCs 3100, 3125 in the sense that they must be “asfavorable as” the terms required by those PERCs. The negotiation resultshown includes, for example, a “negotiated” control set 3162 that insome sense corresponds to the control set 3102 a of the FIG. 75A PERC3100 and to the control set 3131 a of the FIG. 75B control set 3125.Resulting “negotiated” control set 3162 thus includes a required BUDGETmethod 3164 that corresponds to the control set 3125 desired BUDGETmethod 3142 but which is “within” the range of control sets allowed bycontrol set 3100 required BUDGET method 3112. Similarly, resultingnegotiated control set 3162 includes a required AUDIT method 3166 thatcomplies with the requirements of both PERC 3100 required AUDIT method3114 and PERC 3125 required AUDIT method 3135. Similarly, resultingnegotiated control set 3162 includes a required BILLING method 3170 that“matches” or complies with each of PERC 3100 required BILLING method3116 and PERC 3125 required BILLING method 3170.

[2163] Another class of negotiation is one under which no rules arefixed and only the desired goals are specified. The negotiationprocesses for this type of negotiation may be very complex. It mayutilize artificial intelligence, fuzzy logic, and/or related algorithmsto reach their goals. VDE supports these types of processes by providinga mechanism for concisely specifying rights, control information, fieldsand goals (in the form of desired rights, control information, andfields). Goals for these types of processes might be specified as onemore control sets that contain specific elements that are tagged asoptional, permitted, or desired.

[2164] Types of Negotiations

[2165] Negotiations in the preferred embodiment may be structured in anyof the following ways:

[2166] 1. shared knowledge

[2167] 2. trusted negotiator

[2168] 3. “zero-based” knowledge

[2169] “Shared knowledge” negotiations are based on all parties knowingall of the rules and constraints associated with the negotiation. Demandnegotiations are a simple case of shared knowledge negotiations; thedemander presents a list of demands that must be accepted or rejectedtogether. The list of demands comprises a complete set of knowledgerequired to accept or reject each item on the list. VDE enables thisclass of negotiation to occur electronically by providing a mechanism bywhich demands may be encoded, securely passed, and securely processedbetween and with secure VDE subsystems using VDE secure processing, andcommunication capabilities. Other types of shared knowledge negotiationsemployed by VDE involve the exchange of information between two or morenegotiating parties; the negotiation process(es) can independentlydetermine desired final outcome(s) based on their independentpriorities. The processes can then negotiate over any differences.Shared knowledge negotiations may require a single negotiation process(as in a demand type negotiation) or may involve two or more cooperativeprocesses. FIGS. 76A and 76B illustrate scenarios in which one and twonegotiation processes are used in a shared knowledge negotiation.

[2170]FIG. 76A shows a single negotiation process 3172 that takes anynumber of PERCs 808 (e.g., supplied by different parties) as inputs tothe negotiation. The negotiation process 3172 executes at a VDE nodeunder supervision of “Negotiation Process Rules and Control information”that may be supplied by a further PERC (e.g., PERC 3150 shown in FIG.75C). The process 3172 generates one or more PERCs/URTs 3160 as resultsof the negotiation.

[2171]FIG. 76B shows multiple negotiation processes 3172A-3172N each ofwhich takes as input a PERC 808 from a party and a further PERC 3150that controls the negotiation process, and each of which generates anegotiated “result” PERC/URT 3160 as output. Processes 3172A-3172N mayexecute at the same or different VDE nodes and may communicate using a“negotiation protocol.”

[2172] Single and multiple negotiation processes may be used forspecific VDE sites. The negotiation processes are named, and can beaccessed using well known method names. PERCs and URTs may betransported in administrative or smart objects to remote VDE sites forprocessing at that site, as may the control PERCs and REGISTER methodthat controls the negotiation.

[2173] Multiple negotiation processes require the ability to communicatebetween these processes 3172; including secure communication betweensecure processes that are present at physically separate VDE sites(secure subsystems). VDE generalizes the inter-process communicationinto a securely provided service that can be used if the configurationrequires it. The inter-process communication uses a negotiation protocolto exchange information about rule sets between processes 3172. Anexample of a negotiation protocol includes the following negotiation“primitives”: WANT Want a set of terms and conditions ACCEPT Accept aset of terms and conditions REJECT Reject a set of terms and conditionsOFFER Offer a set of terms and conditions in exchange for other termsand conditions HAVE Assert a set of terms and conditions are possible ordesirable QUIT Assert the end of the negotiation without reaching anagreement AGREEMENT Conclude the negotiation and pass the rule set forsignature

[2174] The WANT primitive takes rights and control set (or parts ofcontrol sets) information, and asserts to the other process(es) 3172that the specified terms are desired or required. Demand negotiationsare a simple case of a WANT primitive being used to assert the demand.This example of a protocol may introduce a refined form of the WANTprimitive, REQUIRE. In this example, REQUIRE allows a party to set termsthat she decides are necessary for a contract to be formed, WANT mayallow the party to set terms that are desirable but not essential. Thispermits a distinction between “must have” and “would like to have.”

[2175] In this example, WANT primitives must always be answered by anACCEPT, REJECT, or OFFER primitive. The ACCEPT primitive permits anegotiation process 3172 to accept a set of terms and conditions. TheREJECT primitive permits a process 3172 to reject an offered set ofterms and conditions. Rejecting a set of required terms and conditionsmay terminate the negotiation. OFFER permits a counter-offer to be made.

[2176] The HAVE, QUIT, and AGREEMENT primitives permit the negotiationprotocols to pass information about rule sets. Shared knowledgenegotiations may, for example, start with all negotiation processes3172A-3172N asserting HAVE (my PERC) to the other processes. HAVE isalso used when an impasse is reached and one process 3172 needs to letthe other process 3172 know about permitted options. QUIT signals anunsuccessful end of the negotiation without reaching an agreement, whileAGREEMENT signals a successful end of an agreement and passes theresulting “negotiated” PERC/URT 3160 to the other process(es) 3172 forsignature.

[2177] In “trusted negotiator” negotiations, all parties provide theirdemands and preferences to a “trusted” negotiator and agree to be boundby her decision. This is similar to binding arbitration in today'ssociety. VDE enables this mode of negotiation by providing anenvironment in which a “trusted” negotiation service may be created. VDEprovides not only the mechanism by which demands, desires, and limitsmay be concisely specified (e.g., in PERCs), but in which the PERCs maybe securely transferred to a “trusted” negotiation service along with arule set that specifies how the negotiation will be conducted, and byproviding a secure execution environment so that the negotiation processmay not be tampered with. Trusted negotiator services can be used at VDEsites where the integrity of the site is well known. Remote trustednegotiation services can be used by VDE sites that do not possesssufficient computing resources to execute one or more negotiationprocess(es); they can establish a communication link to a VDE site thatprovides this service and permits the service to handle the negotiationon their behalf.

[2178] “Zero-based” knowledge negotiations share some characteristics ofthe zero-based knowledge protocols used for authentication. It is wellunderstood in the art how to construct a protocol that can determine ifa remote site is the holder of a specific item without exchanging orexposing the item. This type of protocol can be constructed between twonegotiation processes operating on at least one VDE site using a controlset as their knowledge base. The negotiation processes may exchangeinformation about their control sets, and may make demands and counterproposals regarding using their individual rule sets. For example,negotiation process A may communicate with negotiation process B tonegotiate rights to read a book. Negotiation process A specifies that itwill pay not more than $10.00 for rights to read the book, and prefersto pay between $5.00 and $6.00 for this right. Process A's rule set alsospecifies that for the $5.00 option, it will permit the release of thereader's name and address. Process B's rule set specifies that it wants$50.00 for rights to read the book, and will provide the book for $5.50if the user agrees to release information about himself. The negotiationmight go something like this: Process A ⇄ Process B Want (right to read,unrestricted) → ← Have(right to read, unrestricted, $50) Offer (right toread, tender → user info) ← Have(right to read, tender user info, $5.50)Accept (right to read, tender → user info, $5.50)

[2179] In the above example, process A first specifies that it desiresthe right to read the book without restrictions or other informationrelease. This starting position is specified as a rights option in thePERC that process A is using as a rule. Process B checks its rules anddetermines that an unrestricted right to read is indeed permitted for aprice of $50. It replies to process A that these terms are available.Process A receives this reply and checks it against the control set inthe PERC it uses as a rule base. The $50 is outside the $10 limitspecified for this control set, so Process A cannot accept the offer. Itmakes a counter offer (as described in another optional rights option)of an unrestricted right to read coupled with the release of thereader's name and address. The name and address fields are described ina DTD referenced by Process A's PERC. Process B checks its rules PERCand determines that an unrestricted right to read combined with therelease of personal information is a permitted option. It compares thefields that would be released as described in the DTD provided byProcess A against the desired fields in a DTD in its own PERC, anddetermines an acceptable match has occurred. It then sends an offer forunrestricted rights with the release of specific information for thecost of $5.50 to Process A. Process A compares the right, restrictions,and fields against its rule set and determines that $5.50 is within therange of $5-$6 described as acceptable in its rule set. It accepts theoffer as made. The offer is sealed by both parties “signing” a new PERCthat describes the results of the final negotiation (unrestrictedrights, with release of user information, for $5.50). The new PERC maybe used by the owner of Process A to read the content (the book) subjectto the described terms and conditions.

[2180] Further Chain of Handling Model

[2181] As described in connection with FIG. 2, there are four (4)“participant” instances of VDE 100 in one example of a VDE chain ofhandling and control used, for example, for content distribution. Thefirst of these participant instances, the content creator 102, ismanipulated by the publisher, author, rights owner or distributor of aliterary property to prepare the information for distribution to theconsumer. The second participant instance, VDE rights distributor 106,may distribute rights and may also administer and analyze customers' useof VDE authored information. The third participant instance, contentuser 112, is operated by users (included end-users and distributors)when they use information. The fourth participant instance, financialclearinghouse 116 enables the VDE related clearinghouse activities. Afurther participant, a VDE administrator, may provide support to keepVDE 100 operating properly. With appropriate authorizations and RightsOperating System components installed, any VDE electronic appliance 600can play any or all of these participant roles.

[2182] Literary property is one example of raw material for VDE 100. Totransfer this raw material into finished goods, the publisher, author,or rights owner uses tools to transform digital information (such aselectronic books, databases, computer software and movies) intoprotected digital packages called “objects.” Only those consumers (orothers along the chain of possession such as a redistributor) whoreceive permission from a distributor 106 can open these packages. VDEpackaged content can be constrained by “rules and control information”provided by content creator 102 and/or content distributor 106—or byother VDE participants in the content's distribution pathway, i.e.,normally by participants “closer” to the creation of the VDE securedpackage than the participant being constrained.

[2183] Once the content is packaged in an “object,” the digitaldistribution process may begin. Since the information packagesthemselves are protected, they may be freely distributed on CD-ROMdisks, through computer networks, or broadcast through cable or byairwaves. Informal “out of channel” exchange of protected packages amongend-users does not pose a risk to the content property rights. This isbecause only authorized individuals may use such packages. In fact, such“out of channel” distribution may be encouraged by some contentproviders as a marginal cost method of market penetration. Consumerswith usage authorizations (e.g., a VISA clearinghouse budget allowing acertain dollar amount of usage) may, for example, be free to licenseclasses of out of channel VDE protected packages provided to them, forexample, by a neighbor.

[2184] To open a VDE package and make use of its content, an end-usermust have permission. Distributors 106 can grant these permissions, andcan very flexibly (if permitted by senior control information) limit orotherwise specify the ways in which package contents may be used.Distributors 106 and financial clearinghouses 116 also typically havefinancial responsibilities (they may be the same organization in somecircumstances if desired). They ensure that any payments required fromend-users fulfill their own and any other participant's requirements.This is achieved by auditing usage.

[2185] Distributors 106 using VDE 100 may include software publishers,database publishers, cable, television, and radio broadcasters, andother distributors of information in electronic form. VDE 100 supportsall forms of electronic distribution, including distribution bybroadcast or telecommunications, or by the physical transfer ofelectronic storage media. It also supports the delivery of content inhomogeneous form, seamlessly integrating information from multipledistribution types with separate delivery of permissions, controlmechanisms and content.

[2186] Distributors 106 and financial clearinghouses 116 may themselvesbe audited based on secure records of their administrative activitiesand a chain of reliable, “trusted” processes ensures the integrity ofthe overall digital distribution process. This allows content owners,for example, to verify that they are receiving appropriate compensationbased on actual content usage or other agreed-upon bases.

[2187] Since the end-user 112 is the ultimate consumer of content inthis example, VDE 100 is designed to provide protected content in aseamless and transparent way—so long as the end-user stays within thelimits of the permissions she has received. The activities of end-user112 can be metered so that an audit can be conducted by distributors106. The auditing process may be filtered and/or generalized to satisfyuser privacy concerns. For example, metered, recorded VDE content and/orappliance usage information may be filtered prior to reporting it todistributor 106 to prevent more information than necessary from beingrevealed about content user 112 and/or her usage.

[2188] VDE 100 gives content providers the ability to recreate importantaspects of their traditional distribution strategies in electronic formand to innovatively structure new distribution mechanisms appropriate totheir individual needs and circumstances. VDE 100 supports relevantparticipants in the chain of distribution, and also enables theirdesired pricing strategies, access and redistribution permissions, usagerules, and related administrative and analysis procedures. The reusablefunctional primitives of VDE 100 can be flexibly combined by contentproviders to reflect their respective distribution objectives. As aresult, content providers can feed their information into establisheddistribution channels and also create their own personalizeddistribution channels.

[2189] A summary of the roles of the various participants of virtualdistribution environment 100 is set forth in the table below: RoleDescription “Traditional” Participants Content creator Packager andinitial distributor of digital information Content owner Owner of thedigital information. Distributors Provide rights distribution servicesfor budgets and/or content. Auditor Provides services for processing andreducing usage based audit trails. Clearinghouse Provides intermediatestore and forward services for content and audit information. Also,typically provides a platform for other services, including third partyfinancial providers and auditors. Network provider Providescommunication services between sites and other participants. FinancialProvider of third party sources of providers electronic funds toend-users and distributors. Examples of this class of users are VISA,American Express, or a government. End Users Consumers of information.Other Participants Redistributor Redistributes rights to use contentbased on chain of handling restrictions from content providers and/orother distributors. VDE Provider of trusted services for support ofAdministrator VDE nodes. Independent Provider of services for processingand Audit Processor summarizing audit trail data. Provides anonymity toend-users while maintaining the comprehensive audit capabilitiesrequired by the content providers. Agents Provides distributed presencefor end- users and other VDE participants.

[2190] Of these various VDE participants, the “redistributor,” “VDEAdministrator,” “independent audit processor” and “agents” are, incertain respects “new” participants that may have no counterpart in many“traditional” business models. The other VDE participants (i.e., contentprovider, content owner, distributors, auditor, clearinghouse, networkprovider and financial providers) have “traditional” business modelcounterparts in the sense that traditional distribution models oftenincluded non-electronic participants performing some of the samebusiness roles they serve in the virtual distribution environment 100.

[2191] VDE distributors 106 may also include “end-users” who provideelectronic information to other end-users. For example, FIG. 77 shows afurther example of a vial distribution environment 100 chain of handlingand control provided by the present invention. As compared to FIG. 2,FIG. 77 includes a new “client administrator” participant 700. Inaddition, FIG. 77 shows several different content users 112(1), 112(2),. . . , 112(n) that may all be subject to the “jurisdiction” of theclient administrator 700. Client administrator 700 may be, for example,a further rights distributor within a corporation or other organizationthat distributes rights to employees or other organization participantunits (such as divisions, departments, networks, and or groups, etc.)subject to organization-specific “rules and control information.” Theclient administrator 700 may fashion rules and control information fordistribution, subject to “rules and control” specified by creator 102and/or distributor 106.

[2192] As mentioned above, VDE administrator 116 b is a trusted VDE nodethat supports VDE 100 and keeps it operating properly. In this example,VDE administrator 116 b may provide, among others, any of all of thefollowing:

[2193] VDE appliance initialization services

[2194] VDE appliance reinitialization/update services

[2195] Key management services

[2196] “Hot lists” of “rogue” VDE sites

[2197] Certification authority services

[2198] Public key registration

[2199] Client participant unit content budgets and other authorizations

[2200] All participants of VDE 100 have the innate ability toparticipate in any role. For example, users may gather together existingprotected packages, add (create new content) packages of their own, andcreate new products. They may choose to serve as their own distributor,or delegate this responsibility to others. These capabilities areparticularly important in the object oriented paradigm which is enteringthe marketplace today. The production of compound objects, objectlinking and embedding, and other multi-source processes will create aneed for these capabilities of VDE 100. The distribution processprovided by VDE 100 is symmetrical; any end-user may redistributeinformation received to other end-users, provided they possesspermission from and follow the rules established by the distributionchain VDE control information governing redistribution. End-users alsomay, within the same rules and permissions restriction, encapsulatecontent owned by others within newly published works and distributethese works independently. Royalty payments for the new works may beaccessed by the publisher, distributors, or end-users, and may betracked and electronically collected at any stage of the chain.

[2201] Independent financial providers can play an important role in VDE100. The VDE financial provider role is similar to the role played byorganizations such as VISA in traditional distribution scenarios. In anydistribution model, authorizing payments for use of products or servicesand auditing usage for consistency and irregularities, is critical. InVDE 100, these are the roles filled by independent financial providers.The independent financial providers may also provide audit services tocontent providers. Thus, budgets or limits on use, and audits, orrecords of use, may be processed by (and may also be put in place by)clearinghouses 116, and the clearinghouses may then collect usagepayments from users 112. Any VDE user 112 may assign the right toprocess information or perform services on their behalf to the extendallowed by senior control information. The arrangement by which one VDEparticipant acts on behalf of another is called a “proxy.” Audit,distribution, and other important rights may be “proxied” if permittedby the content provider. One special type of “proxy” is the VDEadministrator 116 b. A VDE administrator is an organization (which maybe acting also as a financial clearinghouse 116) that has permission tomanage (for example, “intervene” to reset) some portion or all of VDEsecure subsystem control information for VDE electronic appliances. Thisadministration right may extend only to admitting new appliances to aVDE infrastructure and to recovering “crashed” or otherwise inoperableappliances, and providing periodic VDE updates.

[2202] More on Object Creation, Distribution Methods, Budgets, andAudits

[2203] VDE node electronic appliances 600 in the preferred embodimentcan have the ability to perform object creation, distribution, auditcollection and usage control functions provided by the presentinvention. Incorporating this range of capabilities within each of manyelectronic appliances 600 provided by the preferred embodiment isimportant to a general goal of creating a single (or prominent) standardfor electronic transactions metering, control, and billing, that, in itssum of installations, constitutes a secure, trusted, virtualtransaction/distribution management environment. If, generally speaking,certain key functions were generally or frequently missing, at least ingeneral purpose VDE node electronic appliances 600, then a variety ofdifferent products and different standards would come forth to satisfythe wide range of applications for electronic transaction/distributionmanagement; a single consistent set of tools and a single “rational,”trusted security and commercial distribution environment will not havebeen put in place to answer the pressing needs of the evolving“electronic highway.” Certain forms of certain electronic appliances 600containing VDE nodes which incorporate embedded dedicated VDEmicrocontrollers such as certain forms of video cassette players, cabletelevision converters and the like may not necessarily have or need fullVDE capabilities. However, the preferred embodiment provides a number ofdistributed, disparately located electronic appliances 600 each of whichdesirably include authoring, distribution, extraction, audit, and auditreduction capabilities, along with object authoring capabilities.

[2204] The VDE object authoring capabilities provided by the preferredembodiment provides an author, for example, with a variety of menus forincorporating methods in a VDE object 300, including:

[2205] menus for metering and/or billing methods which define how usageof the content portion of a VDE object is to be controlled,

[2206] menus related to extraction methods for limiting and/or enablingusers of a VDE object from extracting information from that object, andmay include placing such information in a newly created and/orpre-existing VDE content container,,

[2207] menus for specifying audit methods—that is, whether or notcertain audit information is to be generated and communicated in somesecure fashion back to an object provider, object creator,administrator, and/or clearinghouse, and

[2208] menus for distribution methods for controlling how an object isdistributed, including for example, controlling distribution rights ofdifferent participant's “down” a VDE chain of content containerhandling.

[2209] The authoring capabilities may also include procedures fordistributing administrative budgets, object distribution control keys,and audit control keys to distributors and other VDE participants whoare authorized to perform distribution and/or auditing functions onbehalf of the author, distributors, and/or themselves. The authoringcapabilities may also include procedures for selecting and distributingdistribution methods, audit methods and audit reduction methods,including for example, securely writing and/or otherwise controllingbudgets for object redistribution by distributors to subsequent VDEchain of content handling participants.

[2210] The content of an object 300 created by an author may begenerated with the assistance of a VDE aware application program or anon-VDE aware application program. The content of the object created byan author in conjunction with such programs may include text, formattedtext, pictures, moving pictures, sounds, computer software, multimedia,electronic games, electronic training materials, various types of files,and so on, without limitation. The authoring process may encapsulatecontent generated by the author in an object, encrypt the content withone or more keys, and append one or more methods to define parameters ofallowed use and/or required auditing of use and/or payment for use ofthe object by users (and/or by authorized users only). The authoringprocess may also include some or all aspects of distributing the object.

[2211] In general, in the preferred embodiment, an author can:

[2212] A. Specify what content is to be included in an object.

[2213] B. Specify content oriented methods including:

[2214] Information—typically abstract, promotional, identifying,scheduling, and/or other information related to the content and/orauthor

[2215] Content—e.g. list of files and/or other information resourcescontaining content, time variables, etc.

[2216] C. Specify control information (typically a collection of methodsrelated to one another by one or more permissions records, including anymethod defining variables) and any initial authorized user listincluding, for example:

[2217] Control information over Access & Extraction

[2218] Control information over Distribution

[2219] Control information over Audit Processing

[2220] A VDE node electronic appliance 600 may, for example, distributean object on behalf of an object provider if a VDE node receives from anobject provider administrative budget information for distributing theobject and associated distribution key information.

[2221] A VDE node electronic appliance 600 may receive and process auditrecords on behalf of an object provider if that VDE node receives anynecessary administrative budget, audit method, and audit key information(used, for example, to decrypt audit trails), from the object provider.An auditing-capable VDE electronic appliance 600 may control executionof audit reduction methods. “Audit reduction” in the preferredembodiment is the process of extracting information from audit recordsand/or processes that an object provider (e.g., any object provideralong a chain of handling of the object) has specified to be reported toan object's distributors, object creators, client administrators, and/orany other user of audit information. This may include, for example,advertisers who may be required to pay for a user's usage of objectcontent. In one embodiment, for example, a clearinghouse can have theability to “append” budget, audit method, and/or audit key informationto an object or class or other grouping of objects located at a usersite or located at an object provider site to ensure that desired auditprocesses will take place in a “trusted” fashion. A participant in achain of handling of a VDE content container and/or content containercontrol information object may act as a “proxy” for another party in achain of handling of usage auditing information related to usage ofobject content (for example a clearinghouse, an advertiser, or a partyinterested in market survey and/or specific customer usage information).This may be done by specifying, for that other party, budget, auditmethod, and/or key information that may be necessary to ensure auditinformation is gathered and/or provided to, in a proper manner, saidadditional party. For example, employing specification informationprovided by said other party.

[2222] Object Creation and Initial Control Structures

[2223] The VDE preferred embodiment object creation and controlstructure design processes support fundamental configurability ofcontrol information. This enables VDE 100 to support a full range ofpossible content types, distribution pathways, usage controlinformation, auditing requirements, and users and user groups. VDEobject creation in the preferred embodiment employs VDE templates whoseatomic elements represent at least in part modular control processes.Employing VDE creation software (in the preferred embodiment a GUIprogramming process) and VDE templates, users may create VDE objects 300by, for example, partitioning the objects, placing “meta data” (e.g.,author's name, creation date, etc.) into them, and assigning rightsassociated with them and/or object content to, for example, a publisherand/or content creator. When an object creator runs through thisprocess, she normally will go through a content specification procedurewhich will request required data. The content specification process,when satisfied, may proceed by, for example, inserting data into atemplate and encapsulating the content. In addition, in the preferredembodiment, an object may also automatically register its presence withthe local VDE node electronic appliance 600 secure subsystem, and atleast one permissions record 808 may be produced as a result of theinteraction of template instructions and atomic methods, as well as oneor more pieces of control structure which can include one or moremethods, budgets, and/or etc. A registration process may require abudget to be created for the object. If an object creation processspecifies an initial distribution, an administrative object may also becreated for distribution. The administrative object may contain one ormore permission records 808, other control structures, methods, and/orload modules.

[2224] Permissions records 808 may specify various control relationshipsbetween objects and users. For example, VDE 100 supports both singleaccess (e.g., one-to-one relationship between a user and a right user)and group access (any number of people may be authorized as a group). Asingle permissions record 808 can define both single and group access.VDE 100 may provide “sharing,” a process that allows multiple users toshare a single control budget as a budget. Additional control structureconcepts include distribution, redistribution, and audit, the lattersupporting meter and budget information reduction and/or transfer. Allof these processes are normally securely controlled by one or more VDEsecure subsystems.

[2225] Templates and Classes

[2226] VDE templates, classes, and flexible control structures supportframeworks for organizations and individuals that create, modify,market, distribute, redistribute, consume, and otherwise use movies,audio recordings and live performances, magazines, telephony basedretail sales, catalogs, computer software, information databases,multimedia, commercial communications, advertisements, market surveys,infomercials, games, CAD/CAM services for numerically controlledmachines, and the like. As the context surrounding these classes changesor evolves, the templates provided by the preferred embodiment of thepresent invention can be modified to meet these changes for broad use,or more focused activities.

[2227] VDE 100 authoring may provide three inputs into a create process:Templates, user input and object content. Templates act as a set ofcontrol instructions and/or data for object control software which arecapable of creating (and/or modifying) VDE objects in a process thatinteracts with user instructions and provided content to create a VDEobject. Templates are usually specifically associated with objectcreation and/or control structures. Classes represent user groups whichcan include “natural” groups within an organization, such as departmentmembers, specific security clearance levels, etc., or ad hoc lists ofindividual's and/or VDE nodes.

[2228] For example, templates may be represented as text files definingspecific structures and/or component assemblies. Templates, with theirstructures and/or component assemblies may serve as VDE object authoringor object control applications. A creation template may consist of anumber of sub-templates, which, at the lowest level, represent an“atomic level” of description of object specification. Templates maypresent one or more models that describe various aspects of a contentobject and how the object should be created including employing secureatomic methods that are used to create, alter, and/or destroypermissions records 808 and/or associated budgets, etc.

[2229] Templates, classes (including user groups employing an objectunder group access), and flexible control structures including object“independent” permissions records (permissions that can be associatedwith a plurality of objects) and structures that support budgeting andauditing as separate VDE processes, help focus the flexible andconfigurable capabilities inherent within authoring provided by thepresent invention in the context of specific industries and/orbusinesses and/or applications. VDE rationalizes and encompassesdistribution scenarios currently employed in a wide array of powerfulindustries (in part through the use of application or industry specifictemplates). Therefore, it is important to provide a framework ofoperation and/or structure to allow existing industries and/orapplications and/or businesses to manipulate familiar concepts relatedto content types, distribution approaches, pricing mechanisms, userinteractions with content and/or related administrative activities,budgets, and the like.

[2230] The VDE templates, classes, and control structures are inherentlyflexible and configurable to reflect the breadth of informationdistribution and secure storage requirements, to allow for efficientadaptation into new industries as they evolve, and to reflect theevolution and/or change of an existing industry and/or business, as wellas to support one or more groups of users who may be associated withcertain permissions and/or budgets and object types. The flexibility ofVDE templates, classes, and basic control structures is enhanced throughthe use of VDE aggregate and control methods which have a compound,conditional process impact on object control. Taken together, andemployed at times with VDE administrative objects and VDE securityarrangements and processes, the present invention truly achieves acontent control and auditing architecture that can be configured to mostany commercial distribution embodiment. Thus, the present inventionfully supports the requirements and biases of content providers withoutforcing them to fit a predefined application model. It allows them todefine the rights, control information, and flow of their content (andthe return of audit information) through distribution channels.

[2231] Modifying Object Content (Adding, Hiding, Modifying, Removing,and/or Extending)

[2232] Adding new content to objects is an important aspect of authoringprovided by the present invention. Providers may wish to allow one ormore users to add, hide, modify, remove and/or extend content that theyprovide. In this way, other users may add value to, alter for a newpurpose, maintain, and/or otherwise change, existing content. Theability to add content to an empty and/or newly created object isimportant as well.

[2233] When a provider provides content and accompanying controlinformation, she may elect to add control information that enablesand/or limits the addition, modification, hiding and/or deletion of saidcontent. This control information may concern:

[2234] the nature and/or location of content that may be added, hidden,modified, and/or deleted;

[2235] portions of content that may be modified, hidden, deleted and/oradded to;

[2236] required secure control information over subsequent VDE containercontent usage in a chain of control and/or locally to added, hidden,and/or modified content;

[2237] requirements that provider-specified notices and/or portions ofcontent accompany added, hidden, deleted and/or modified content and/orthe fact that said adding, hiding, modification and/or deletionoccurred;

[2238] secure management of limitations and/or requirements concerningcontent that may be removed, hidden and/or deleted from content,including the amount and/or degree of addition, hiding, modificationand/or deletion of content;

[2239] providing notice to a provider or providers that modification,hiding, addition and/or deletion has occurred and/or the nature of saidoccurrence; and

[2240] other control information concerned with modification, addition,hiding, and/or deleting provider content.

[2241] A provider may use this control information to establish anopportunity for other users to add value to and/or maintain existingcontent in a controlled way. For example, a provider of softwaredevelopment tools may allow other users to add commentary and/or similarand/or complementary tools to their provided objects. A provider ofmovies may allow commentary and/or promotional materials to be added totheir materials. A provider of CAD/CAM specifications to machine toolowners may allow other users to modify objects containing instructionsassociated with a specification to improve and/or translate saidinstructions for use with their equipment. A database owner may allowother users to add and/or remove records from a provided database objectto allow flexibility and/or maintenance of the database.

[2242] Another benefit of introducing control information is theopportunity for a provider to allow other users to alter content for anew purpose. A provider may allow other users to provide content in anew setting.

[2243] To attach this control information to content, a provider may beprovided with, or if allowed, design and implement, a method or methodsfor an object that govern addition, hiding, modification and/or deletionof content. Design and implementation of such one or more methods may beperformed using VDE software tools in combination with a PPE 650. Theprovider may then attach the method(s) to an object and/or provide themseparately. A permissions record 808 may include requirements associatedwith this control information in combination with other controlinformation, or a separate permissions record 808 may be used.

[2244] An important aspect of adding or modifying content is the choiceof encryption/decryption keys and/or other relevant aspects of securingnew or altered content. The provider may specify in their method(s)associated with these processes a technique or techniques to be used forcreating and/or selecting the encryption/decryption keys and/or otherrelevant aspect of securing new and/or altered content. For example, theprovider may include a collection of keys, a technique for generatingnew keys, a reference to a load module that will generate keys, aprotocol for securing content, and/or other similar information.

[2245] Another important implication is the management of new keys, ifany are created and/or used. A provider may require that such keys andreference to which keys were used must be transmitted to the provider,or she may allow the keys and/or securing strategy to remain outside aprovider's knowledge and/or control. A provider may also choose anintermediate course in which some keys must be transmitted and othersmay remain outside her knowledge and/or control.

[2246] An additional aspect related to the management of keys is themanagement of permissions associated with an object resulting from theaddition, hiding, modification and/or deletion of content. A providermay or may not allow a VDE chain of control information user to takesome or all of the VDE rules and control information associated withgranting permissions to access and/or manipulate VDE managed contentand/or rules and control information associated with said resultingobject. For example, a provider may allow a first user to control accessto new content in an object, thereby requiring any other user of thatportion of content to receive permission from the first user. This mayor may not, at the provider's discretion, obviate the need for a user toobtain permission from the provider to access the object at all.

[2247] Keys associated with addition, modification, hiding and/ordeletion may be stored in an independent permissions record or records808. Said permissions record(s) 808 may be delivered to a provider orproviders and potentially merged with an existing permissions record orrecords, or may remain solely under the control of the new contentprovider. The creation and content of an initial permissions record 808and any control information over the permissions record(s) arecontrolled by the method(s) associated with activities by a provider.Subsequent modification and/or use of said permission record(s) mayinvolve a provider's method(s), user action, or both. A user's abilityto modify and/or use permissions record(s) 808 is dependent on, at leastin part, the senior control information associated with the permissionsrecord(s) of a provider.

[2248] Distribution Control Information

[2249] To enable a broad and flexible commercial transactionenvironment, providers should have the ability to establish fir controlinformation over a distribution process without unduly limiting thepossibilities of subsequent parties in a chain of control. Thedistribution control information provided by the present invention allowflexible positive control. No provider is required to include anyparticular control, or use any particular strategy, except as requiredby senior control information. Rather, the present invention allows aprovider to select from generic control components (which may beprovided as a subset of components appropriate to a provider's specificmarket, for example, as included in and/or directly compatible with, aVDE application) to establish a structure appropriate for a given chainof handling/control. A provider may also establish control informationon their control information that enable and limit modifications totheir control information by other users.

[2250] The administrative systems provided by the present inventiongenerate administrative “events.” These “events” correspond toactivities initiated by either the system or a user that correspond topotentially protected processes within VDE. These processes includeactivities such as copying a permissions record, copying a budget,reading an audit trail record, copying a method, updating a budget,updating a permissions record, updating a method, backing up managementfiles, restoring management files, and the like. Reading, writing,modifying, updating, processing, and/or deleting information from anyportion of any VDE record may be administrative events. Anadministrative event may represent a process that performs one or moreof the aforementioned activities on one or more portions of one or morerecords.

[2251] When a VDE electronic appliance 600 encounters an administrativeevent, that event is typically processed in conjunction with a VDE PPE650. As in the case of events generally related to access and/or use ofcontent, in most cases id administrative events are specified by contentproviders (including, for example, content creators, distributors,and/or client administrators) as an aspect of a control specified for anobject, group and/or class of objects.

[2252] For example, if a user initiates a request to distributepermission to use a certain object from a desktop computer to a notebookcomputer, one of the administrative events generated may be to create acopy of a permissions record that corresponds to the object. When thisadministrative event is detected by ROS 602, an EVENT method for thistype of event may be present. If an EVENT method is present, there mayalso be a meter, a billing, and a budget associated with the EVENTmethod. Metering, billing, and budgeting can allow a provider to enableand limit the copying of a permissions record 808.

[2253] For example, during the course of processing a control program, ameter, a billing, and a budget and/or audit records may be generatedand/or updated. Said audit records may record information concerningcircumstances surrounding an administrative event and processing of saidevent. For example, an audit record may contain a reference to a userand/or system activity that initiated an event, the success or failureof processing said event, the date and/or time, and/or other relevantinformation.

[2254] Referring to the above example of a user with both a desktop andnotebook computer, the provider of a permissions record may require anaudit record each time a meter for copying said permissions record isprocessed. The audit record provides a flexible and configurable controland/or recording environment option for a provider.

[2255] In some circumstances, it may be desirable for a provider tolimit which aspects of a control component may be modified, updated,and/or deleted. “Atomic element definitions” may be used to limit theapplicability of events (and therefore the remainder of a controlprocess, if one exists) to certain “atomic elements” of a controlcomponent. For example, if a permissions record 808 is decomposed into“atomic elements” on the fields described in FIG. 26, an eventprocessing chain may be limited, for example, to a certain number ofmodifications of expiration date/time information by specifying onlythis field in an atomic element definition. In another example, apermissions record 808 may be decomposed into atomic elements based oncontrol sets. In this example, an event chain may be limited to eventsthat act upon certain control sets.

[2256] In some circumstances, it may be desirable for a provider tocontrol how administrative processes are performed. The provider maychoose to include in distribution records stored in secure database 610information for use in conjunction with a component assembly 690 thatcontrols and specifies, for example, how processing for a given event inrelation to a given method and/or record should be performed. Forexample, if a provider wishes to allow a user to make copies of apermissions record 808, she may want to alter the permissions recordinternally. For example, in the earlier example of a user with a desktopand a notebook computer, a provider may allow a user to make copies ofinformation necessary to enable the notebook computer based oninformation present in the desktop computer, but not allow any furthercopies of said information to be made by the notebook VDE node. In thisexample, the distribution control structure described earlier wouldcontinue to exist on the desktop computer, but the copies of theenabling information passed to the notebook computer would lack therequired distribution control structure to perform distribution from thenotebook computer. Similarly, a distribution control structure may beprovided by a content provider to a content provider who is adistributor in which a control structure would enable a certain numberof copies to be made of a VDE content container object along withassociated copies of permissions records, but the permissions recordswould be altered (as per specification of the content provider, forexample) so as not to allow end-users who received distributor createdcopies from making further copies for distribution to other VDE nodes.

[2257] Although the preceding example focuses on one particular event(copying) under one possible case, similar processes may be used forreading, writing, modifying, updating, processing, and/or deletinginformation from records and/or methods under any control relationshipcontemplated by the present invention. Other examples include: copying abudget, copying a meter, updating a budget, updating a meter, condensingan audit trail, and the like.

[2258] Creating Custom Methods

[2259] In the preferred embodiment of the present invention, methods maybe created “at will,” or aliased to another method. These two modescontribute to the superior configurability, flexibility, and positivecontrol of the VDE distribution process. Generally, creating a methodinvolves specifying the required attributes or parameters for the dataportion of the method, and then “typing” the method. The typing processtypically involves choosing one or more load modules to process any dataportions of a method. In addition to the method itself, the process ofmethod creation may also result in a method option subrecord forinclusion in, or modification of, a permissions record, and a notationin the distribution records. In addition to any “standard” loadmodule(s) required for exercise of the method, additional load modules,and data for use with those load modules, may be specified if allowed.These event processing structures control the distribution of themethod.

[2260] For example, consider the case of a security budget. One form ofa typical budget might limit the user to 10 Mb of decrypted data permonth. The user wishes to move their rights to use the relevant VDEcontent container object to their notebook. The budget creator mighthave limited the notebook to the same amount, half the original amount,a prorated amount based on the number of moves budgeted for an object,etc. A distribute method (or internal event processing structure)associated with the budget allows the creator of the budget to make adetermination as to the methodology and parameters involved. Of course,different distribution methods may be required for the case ofredistribution, or formal distribution of the method. The aggregate ofthese choices is stored in a permissions record for the method.

[2261] An example of the process steps used for the move of a budgetrecord might look something like this:

[2262] 1) Check the move budget (e.g., to determine the number of movesallowed)

[2263] 2) Copy static fields to new record (e.g., as an encumbrance)

[2264] 3) Decrement the Decr counter in the old record (the originalbudget)

[2265] 4) Increment the Encumbrance counter in the old record

[2266] 5) Write a distribution record

[2267] 6) Write a Distribution Event Id to the new record

[2268] 7) Increment the move meter

[2269] 8) Decrement the move budget

[2270] 9) Increment the Decr counter in the new record

[2271] Creating a Budget

[2272] In the preferred embodiment, to create a budget, a usermanipulates a Graphical User Interface budget distribution application(e.g., a VDE template application). The user fills out any requiredfields for type(s) of budget, expiration cycle(s), auditor(s), etc. Abudget may be specified in dollars, deutsche marks, yen, and/or in anyother monetary or content measurement schema and/or organization. Thepreferred embodiment output of the application, normally has three basicelements. A notation in the distribution portion of secure database 610for each budget record created, the actual budget records, and a methodoption record for inclusion in a permissions record. Under somecircumstances, a budget process may not result in the creation of amethod option since an existing method option may be being used.Normally, all of this output is protected by storage in secure database610 and/or in one or more administrative objects.

[2273] There are two basic modes of operation for a budget distributionapplication in the preferred embodiment. In the first case, the operatorhas an unlimited ability to specify budgets. The budgets resulting fromthis type of activity may be freely used to control any aspect of adistribution process for which an operator has rights, including for usewith “security” budgets such as quantities limiting some aspect ofusage. For example, if the operator is a “regular person,” he may usethese budgets to control his own utilization of objects based on apersonal accounting model or schedule. If the operator is an authorizeduser at VISA, the resulting budgets may have broad implications for anentire distribution system. A core idea is that this mode is controlledstrictly by an operator.

[2274] The second mode of operation is used to create “alias” budgets.These budgets are coupled to a preexisting budget in an operator'ssystem. When an operator fills a budget, an encumbrance is created onthe aliased budget. When these types of budgets are created, the outputincludes two method option subrecords coupled together: the methodoption subrecord for the aliased budget, and a method option subrecordfor the newly created budget. In most cases, the alias budget can beused in place of the original budget if the budget creator is authorizedto modify the method options within the appropriate required methodrecord of a permissions record.

[2275] For example, assume that a user (client administrator) at acompany has the company's VISA budget on her electronic appliance 600.She wants to distribute budget to a network of company users with avariety of preexisting budgets and requirements. She also wants to limituse of the company's VISA budget to certain objects. To do this, shealiases a company budget to the VISA budget. She then modifies (if soauthorized) the permissions record for all objects that the company willallow their users to manipulate so that they recognize the companybudget in addition to, or instead of, the VISA budget. She thendistributes the new permissions records and budgets to her users. Theaudit data from these users is then reduced against the encumbrance onthe company's VISA budget to produce a periodic billing.

[2276] In another example, a consumer wants to control his family'selectronic appliance use of his VISA card, and prevent his children fromplaying too many video games, while allowing unlimited use ofencyclopedias. In this case, he could create two budgets. The firstbudget can be aliased to his VISA card, and might only be used withencyclopedia objects (referenced to individual encyclopedia objectsand/or to one or more classes of encyclopedia objects) that referencethe aliased budget in their explicitly modified permissions record. Thesecond budget could be, for example, a time budget that he redistributesto the family for use with video game objects (video game class). Inthis instance, the second budget is a “self-replenishing”security/control budget, that allows, for example, two hours of use perday. The first budget operates in the same manner as the earlierexample. The second budget is added as a new required method topermissions records for video games. Since the time budget is requiredto access the video games, an effective control path is introduced forrequiring the second budget—only permissions records modified to acceptthe family budget can be used by the children for video games and theyare limited to two hours per day.

[2277] Sharing and Distributing Rights and Budgets

[2278] Move

[2279] The VDE “move” concept provided by the preferred embodimentcovers the case of “friendly sharing” of rights and budgets. A typicalcase of “move” is a user who owns several machines and wishes to use thesame objects on more than one of them. For example, a user owns adesktop and a notebook computer. They have a subscription to anelectronic newspaper that they wish to read on either machine, i.e., theuser wishes to move rights from one machine to the other.

[2280] An important concept within “move” is the idea of independentoperation. Any electronic appliance 600 to which rights have been movedmay contact distributors or clearinghouses independently. For example,the user mentioned above may want to take their notebook on the road foran extended period of time, and contact clearinghouses and distributorswithout a local connection to their desktop.

[2281] To support independent operation, the user should be able todefine an account with a distributor or clearinghouse that isindependent of the electronic appliance 600 she is using to connect. Thetransactions must be independently traceable and reconcilable among andbetween machines for both the end user and the clearinghouse ordistributor. The basic operations of moving rights, budgets, and bitmapor compound meters between machines is also supported.

[2282] Redistribution

[2283] Redistribution forms a UDE middle ground between the “friendlysharing” of “move,” and formal distribution. Redistribution can bethought of as “anonymous distribution” in the sense that no specialinteraction is required between a creator, clearinghouse, or distributorand a redistributor. Of course, a creator or distributor does have theability to limit or prevent redistribution.

[2284] Unlike the “move” concept, redistribution does not implyindependent operation. The redistributor serves as one point of contactfor users receiving redistributed rights and/or budgets, etc. Theseusers have no knowledge of, or access to, the clearinghouse (or and/ordistributor) accounts of the redistributor. The redistributor serves asan auditor for the rights and/or budgets, etc. that they redistribute,unless specifically overridden by restrictions from distributors and/orclearinghouses. Since redistributees (recipients of redistributed rightsand/or budgets, etc.) would place a relatively unquantifiable workloadon clearinghouses, and furthermore, since a redistributor would beplacing himself at an auditable risk (responsible for all redistributedrights and/or budgets, etc.), the audit of rights, budgets, etc. ofredistributees by redistributors is assumed as the default case in thepreferred embodiment.

[2285] Distribution

[2286] Distribution involves three types of entity. Creators usually arethe source of distribution. They typically set the control structure“context” and can control the rights which are passed into adistribution network. Distributors are users who form a link betweenobject (content) end users and object (content) creators. They canprovide a two-way conduit for rights and audit data. Clearinghouses mayprovide independent financial services, such as credit and/or billingservices, and can serve as distributors and/or creators. Through apermissions and budgeting process, these parties collectively canestablish fine control over the type and extent of rights usage and/orauditing activities.

[2287] Encumbrance

[2288] An “encumbrance” is a special type of VDE budget. When that abudget distribution of any type occurs, an “encumbrance” may begenerated. An encumbrance is indistinguishable from an original budgetfor right exercise (e.g., content usage payment) purposes, but isuniquely identified within distribution records as to the amount of theencumbrance, and all necessary information to complete a shipping recordto track the whereabouts of an encumbrance. For right exercise purposes,an encumbrance is identical to an original budget; but for trackingpurposes, it is uniquely identifiable.

[2289] In the preferred embodiment of the present invention, aDistribution Event ID will be used by user VDE nodes and byclearinghouse services to track and reconcile encumbrances, even in thecase of asynchronous audits. That is, the “new” encumbrance budget isunique from a tracking point of view, but indistinguishable from a usagepoint of view.

[2290] Unresolved encumbrances are a good intermediate control for a VDEdistribution process. A suitable “grace period” can be introduced duringwhich encumbrances must be resolved. If this period elapses, an actualbilling or payment may occur. However, even after the interval hasexpired and the billing and/or payment made, an encumbrance may still beoutstanding and support later reconciliation. In this case, an auditormay allow a user to gain a credit, or a user may connect to a VDE nodecontaining an encumbered budget, and resolve an amount as an internalcredit. In some cases, missing audit trails may concern a distributorsufficiently to revoke redistribution privileges if encumbrances are notresolved within a “grace period,” or if there are repeated grace periodviolations or if unresolved encumbrances are excessively large.

[2291] Encumbrances can be used across a wide variety of distributionmodes. Encumbrances, when used in concert with aliasing of budgets,opens important additional distribution possibilities. In the case ofaliasing a budget, the user places himself in the control path for anobject—an aliased budget may only be used in conjunction withpermissions records that have been modified to recognize it. Anencumbrance has no such restrictions.

[2292] For example, a user may want to restrict his children's use ofhis electronic, VDE node VISA budget. In this case, the user cangenerate an encumbrance on his VISA budget for the children's familyalias budget, and another for his wife that is a transparent encumbranceof the original VISA budget. BigCo may use a similar mechanism todistribute VISA budget to department heads, and aliased BigCo budget tousers directly.

[2293] Account Numbers and User IDs

[2294] In the preferred embodiment, to control access to clearinghouses,users are assigned account numbers at clearinghouses. Account numbersprovide a unique “instance” value for a secure database record from thepoint of view of an outsider. From the point of view of an electronicappliance 600 site, the user, group, or group/user ids provide theunique instance of a record. For example, from the point of view ofVISA, your Gold Card belongs to account number #123456789. From thepoint of view of the electronic appliance site (for example, a server ata corporation), the Gold card might belong to user id 1023. Inorganizations which have plural users and/or user groups using a VDEnode, such users and/or user groups will likely be assigned unique userIDs. differing budgets and/or other user rights may be assigned todifferent users and/or user groups and/or other VDE control informationmay be applied on a differing manner to electronic content and/orappliance usage by users assigned with different such IDs. Of course,both a clearinghouse and a local site will likely have both pieces ofinformation, but “used data” versus the “comment data” may differ basedon perspective.

[2295] In the preferred embodiment case of “move,” an account numberstored with rights stays the same. In the preferred embodiment of otherforms of distribution, a new account number is required for adistributee. This may be generated automatically by the system, orcorrespond to a methodology developed by a distributor or redistributor.Distributors maintain account numbers (and associated access secrets) intheir local name services for each distributee. Conversely,distributees' name services may store account numbers based on user idfor each distributor. This record usually is moved with other records inthe case of move, or is generated during other forms of distribution.

[2296] Organizations (including families) may automatically assignunique user IDs when creating control information (e.g., a budget) for anew user or user group.

[2297] Requirements Record

[2298] In order to establish the requirements, and potentially options,for exercising a right associated with a VDE content container objectbefore one or more required permissions records are received for thatobject, a requirements record may exist in the private header of such anobject. This record will help the user establish what they have, andwhat they need from a distributor prior to forming a connection. If therequirements or possibilities for exercising a particular right havechanged since such an object was published, a modified requirementsrecord may be included in a container with an object (if available andallowed), or a new requirements record may be requested from adistributor before registration is initiated. Distributors may maintain“catalogs” online, and/or delivered to users, of collections ofrequirements records and/or descriptive information corresponding toobjects for which they may have ability to obtain and/or grant rights toother users.

[2299] Passing an Audit

[2300] In the preferred embodiment of VDE there may be at least twotypes of auditing. In the case of budget distribution, billing recordsthat reflect consumption of a budget generally need to be collected andprocessed. In the case of permissions distribution, usage dataassociated with an object are also frequently required.

[2301] In order to effect control over an object, a creator mayestablish the basic control information associated with an object. Thisis done in the formulation of permissions, the distribution of varioussecurity, administrative and/or financial budgets, and the level ofredistribution that is allowed, etc. Distributors (and redistributors)may further control this process within the rights, budgets, etc.(senior control information) they have received.

[2302] For example, an object creator may specify that additionalrequired methods may be added freely to their permissions records,establish no budget for this activity, and allow unlimitedredistribution of this right. As an alternative example, a creator mayallow moving of usage rights by a distributor to half a dozensubdistributors, each of whom can distribute 10,000 copies, but with noredistribution rights being allowed to be allocated to subdistributors'(redistributors') customers. As another example, a creator may authorizethe moving of usage rights to only 10 VDE nodes, and to only one levelof distribution (no redistribution). Content providers and othercontributors of control information have the ability through the use ofpermissions records and/or component assemblies to control rights otherusers are authorized to delegate in the permissions records they send tothose users, so long as such right to control one, some, or all suchrights of other users is either permitted or restricted (depending onthe control information distribution model). It is possible and oftendesirable, using VDE, to construct a mixed model in which a distributoris restricted from controlling certain rights of subsequent users and isallowed to control other rights. VDE control of rights distribution insome VDE models will in part or whole, at least for certain one or more“levels” of a distribution chain, be controlled by electronic contentcontrol information providers who are either not also providers of therelated content or provide only a portion of the content controlled bysaid content control information, for example, in certain models, aclearinghouse might also serve as a rights distribution agent whoprovides one or more rights to certain value chain participants, whichone or more rights may be “attached” to one or more rights to use theclearinghouse's credit (if said clearinghouse is, at least in part, afinancial clearinghouse (such a control information provider mayalternatively, or in addition, restrict other users' rights.

[2303] A content creator or other content control information providermay budget a user (such as a distributor) to create an unlimited numberof permissions records for a content object, but revoke this rightand/or other important usage rights through an expiration/terminationprocess if the user does not report his usage (provide an audit report)at some expected one or more points in time and/or after a certaininterval of time (and/or if the user fails to pay for his usage orviolates other aspects of the agreement between the user and the contentprovider). This termination (or suspension or other specifiedconsequence) can be enforced, for example, by the expiration oftime-aged encryption keys which were employed to encrypt one or moreaspects of control information. This same termination (or otherspecified consequence such as budget reduction, price increase, messagedisplays on screen to users, messages to administrators, etc.) can alsobe the consequence of the failure by a user or the users VDEinstallation to complete a monitored process, such as paying for usagein electronic currency, failure to perform backups of important storedinformation (e.g., content and/or appliance usage information, controlinformation, etc.), failure to use a repeated failure to use the properpasswords or other identifiers, etc.).

[2304] Generally, the collection of audit information that is collectedfor reporting to a certain auditor can be enforced by expiration and/orother termination processes. For example, the user's VDE node may beinstructed (a) from an external source to no longer perform certaintasks, (b) carries within its control structure information informing itto no longer perform certain tasks, or (c) is elsewise no longer able toperform certain tasks. The certain tasks might comprise one or moreenabling operations due to a user's (or installation's) failure toeither report said audit information to said auditor and/or receive backa secure confirmation of receipt and/or acceptance of said auditinformation. If an auditor fails to receive audit information from auser (or some other event fails to occur or occur properly), one or moretime-aged keys which are used, for example, as a security component ofan embodiment of the present invention, may have their aging suddenlyaccelerated (completed) so that one or more processes related to saidtime-aged keys can no longer be performed.

[2305] Authorization Access Tags and Modification Access Tags

[2306] In order to enable a user VDE installation to pass auditinformation to a VDE auditing party such as a Clearinghouse, VDE allowsa VDE auditing party to securely, electronically communicate with theuser VDE installation and to query said installation for certain or allinformation stored within said installation's secure sub-system,depending on said auditing party's rights (said party shall normally beunable to access securely stored information that said party is notexpressly authorized to access, that is one content provider willnormally not be authorized to access content usage information relatedto content provided by a different content provider). The auditing partyasserts a secure secret (e.g., a secure tag) that represents the set ofrights of the auditor to access certain information maintained by saidsubsystem. If said subsystem validates said tag, the auditing party maythen receive auditing information that it is allowed to request andreceive.

[2307] Great flexibility exists in the enforcement of audit trailrequirements. For example, a creator (or other content provider orcontrol information provider or auditor in an object's or audit report'schain of handling) may allow changes by an auditor for event trails, butnot allow anyone but themselves to read those trails, and limit theredistribution of this right to, for example, six levels. Alternatively,a creator or other controlling party may give a distributor the right toprocess, for example, 100,000 audit records (and/or, for example, theright to process 12 audit records from a given user) before reportingtheir usage. If a creator or other controlling party desires, he mayallow (and/or require) separate (and containing different, a subset of,overlapping, or the same information) audit “packets” containing auditinformation, certain of said audit information to be processed by adistributor and certain other of said audit information to be passedback to the creator and/or other auditors (each receiving the same,overlapping, a subset of, or different audit information). Similarly, aslong as allowed by, for example, an object creator, a distributor (orother content and/or control information provider) may require auditinformation to be passed back to it, for example, after every 50,000audit records are processed (or any other unit of quantity and/or aftera certain time interval and/or at a certain predetermined date) by aredistributor. In the preferred embodiment, audit rules, like othercontrol structures, may be stipulated at any stage of a distributionchain of handling as long as the right to stipulate said rules has notbeen restricted by a more “senior” object and/or control informationdistributing (such as an auditing) participant.

[2308] Audit information that is destined for different auditors may beencrypted by different one or more encryption keys which have beensecurely provided by each auditor's VDE node and communicated forinclusion in a user's permissions record(s) as a required step, forexample, during object registration. This can provide additionalsecurity to further ensure (beyond the use of passwords and/or otheridentification information and other VDE security features) that anauditor may only access audit information to which he is authorized. Inone embodiment, encrypted (and/or unencrypted) “packets” of auditinformation (for example, in the form of administrative objects) may bebound for different auditors including a clearinghouse and/or contentproviders and/or other audit information users (including, for example,market analysts and/or list purveyors). The information may passsuccessively through a single chain of handling, for example, user toclearinghouse to redistributor to distributor to publisher/objectcreator, as specified by VDE audit control structures and parameters.Alternatively, encrypted (or, normally less preferably, unencrypted)audit packets may be required to be dispersed directly from a user to aplurality of auditors, some one or more who may have the responsibilityto “pass along” audit packets to other auditors. In another embodiment,audit information may be passed, for example, to a clearinghouse, whichmay then redistribute all and/or appropriate subsets of said information(and/or some processed result) to one or more other parties, saidredistribution employing VDE secure objects created by saidclearinghouse.

[2309] An important function of an auditor (receiver of auditinformation) is to pass administrative events back to a user VDE node inacknowledgement that audit information has been received and/or“recognized.” In the preferred embodiment, the receipt and/or acceptanceof audit information may be followed by two processes. The first eventwill cause the audit data at a VDE node which prepared an audit reportto be deleted, or compressed into, or added to, one or more summaryvalues. The second event, or set of events, will “inform” the relevantsecurity (for example, termination and/or other consequence) controlinformation (for example, budgets) at said VDE node of the auditreceipt, modify expiration dates, provide key updates, and/or etc. Inmost cases, these events will be sent immediately to a site after anaudit trail is received. In some cases, this transmission may be delayedto, for example, first allow processing of the audit trail and/orpayment by a user to an auditor or other party.

[2310] In the preferred embodiment, the administrative events forcontent objects and independently distributed methods/componentassemblies are similar, but not necessarily identical. For example, keyupdates for a budget may control encryption of a billing trail, ratherthan decryption of object content. The billing trail for a budget is inall respects a method event trail. In one embodiment, this trail mustinclude sufficient references into distribution records for encumbrancesto allow reconciliation by a clearinghouse. This may occur, for example,if a grace period elapses and the creator of a budget allows unresolvedencumbrances to ultimately yield automatic credits if an expiredencumbrance is “returned” to the creator.

[2311] Delivery of audit reports through a path of handling may be inpart insured by an inverse (return of information) audit method. ManyVDE methods have at least two pieces: a portion that manages the processof producing audit information at a user's VDE node; and a portion thatsubsequently acts on audit data. In an example of the handling of auditinformation bound for a plurality of auditors, a single container objectis received at a clearinghouse (or other auditor). This container maycontain (a) certain encrypted audit information that is for the use ofthe clearinghouse itself, and (b) certain other encrypted auditinformation bound for other one or more auditor parties. The two sets ofinformation may have the same, overlapping and in part different, orentirely different, information content. Alternatively, theclearinghouse VDE node may be able to work with some or all of theprovided audit information. The audit information may be, in part, orwhole, in some summary and/or analyzed form further processed at theclearinghouse and/or may be combined with other information to form a,at least in part, derived set of information and inserted into one ormore at least in part secure VDE objects to be communicated to said oneor more (further) auditor parties. When an audit information containeris securely processed at said clearinghouse VDE node by said inverse(return) audit method, the clearinghouse VDE node can create one or moreVDE administrative objects for securely carrying audit information toother auditors while separately processing the secure audit informationthat is specified for use by said clearinghouse. Secure audit processesand credit information distribution between VDE participants normallytakes place within the secure VDE “black box,” that is processes aresecurely processed within secure VDE PPE650 and audit information issecurely communicated between the VDE secure subsystems of VDEparticipants employing VDE secure communication techniques (e.g., publickey encryption, and authentication).

[2312] This type of inverse audit method may specify the handling ofreturned audit information, including, for example, the local processingof audit information and/or the secure passing along of auditinformation to one or more auditor parties. If audit information is notpassed to one or more other auditor parties as may be required andaccording to criteria that may have been set by said one or more otherauditor parties and/or content providers and/or control informationproviders during a permissions record specification and/or modificationprocess, the failure to, for example, receive notification of successfultransfer of required audit information by an auditor party, e.g., acontent provider, can result in the disablement of at least somecapability of the passing through party's VDE node (for example,disablement of the ability to further perform certain one or more VDEmanaged business functions that are related to object(s) associated withsaid audit or party). In this preferred embodiment example, when anobject is received by an auditor, it is automatically registered andpermissions record(s) contents are entered into the secure managementdatabase of the auditor's VDE node.

[2313] One or more permissions records that manage the creation and useof an audit report object (and may manage other aspects of object use aswell) may be received by a user's system during an audit informationreporting exchange (or other electronic interaction between a user andan auditor or auditor agent). Each received permissions record maygovern the creation of the next audit report object. After the reportingof audit information, a new permissions record may be required at auser's VDE node to refresh the capability of managing audit reportcreation and audit information transfer for the next audit reportingcycle. In our above example, enabling an auditor to supply one or morepermissions records to a user for the purpose of audit reporting mayrequire that an auditor (such as a clearinghouse) has received certain,specified permissions records itself from “upstream” auditors (such as,for example, content and/or other content control informationproviders). Information provided by these upstream permissions recordsmay be integrated into the one or more permissions records at an auditorVDE (e.g., clearinghouse) installation that manage the permissionsrecord creation cycle for producing administrative objects containingpermissions records that are bound for users during the auditinformation reporting exchange. If an upstream auditor fails to receive,and/or is unable to process, required audit information, this upstreamauditor may fail to provide to the clearinghouse (in this example) therequired permissions record information which enables a distributor tosupport the next permission record creation/auditing cycle for a givenone or more objects (or class of objects). As a result, theclearinghouse's VDE node may be unable to produce the next cycle'spermissions records for users, and/or perform some other importantprocess. This VDE audit reporting control process may be entirelyelectronic process management involving event driven VDE activities atboth the intended audit information receiver and sender and employingboth their secure PPE650 and secure VDE communication techniques.

[2314] In the preferred embodiment, each time a user registers a newobject with her own VDE node, and/or alternatively, with a remoteclearinghouse and/or distributor VDE node, one or more permissionsrecords are provided to, at least in part, govern the use of saidobject. The permissions records may be provided dynamically during asecure UDE registration process (employing the VDE installation securesubsystem), and/or may be provided following an initial registration andreceived at some subsequent time, e.g. through one or more separatesecure VDE communications, including, for example, the receipt of aphysical arrangement containing or otherwise carrying said information.At least one process related to the providing of the one or morepermissions records to a user can trigger a metering event which resultsin audit information being created reflecting the user's VDE node's,clearinghouse's, and/or distributor's permissions records provisionprocess. This metering process may not only record that one or morepermissions records have been created. It may also record the VDE nodename, user name, associated object identification information, time,date, and/or other identification information. Some or all of thisinformation can become part of audit information securely reported by aclearinghouse or distributor, for example, to an auditing contentcreator and/or other content provider. This information can bereconciled by secure VDE applications software at a receiving auditor'ssite against a user's audit information passed through by saidclearinghouse or distributor to said auditor. For each metered one ormore permissions records (or set of records) that were created for acertain user (and/or VDE node) to manage use of certain one or more VDEobject(s) and/or to manage the creation of VDE object audit reports, itmay be desirable that an auditor receive corresponding audit informationincorporated into an, at least in part, encrypted audit report. Thiscombination of metering of the creation of permissions records; secure,encrypted audit information reporting processes; secure VDE subsystemreconciliation of metering information reflecting the creation ofregistration and/or audit reporting permissions with received auditreport detail; and one or more secure VDE installation expiration and/orother termination and/or other consequence processes; taken togethersignificantly enhances the integrity of the VDE secure audit reportingprocess as a trusted, efficient, commercial environment.

[2315] Secure Document Management Example

[2316] VDE 100 may be used to implement a secure document managementenvironment. The following are some examples of how this can beaccomplished.

[2317] In one example, suppose a law firm wants to use VDE 100 to managedocuments. In this example, a law firm that is part of a litigation teammight use VDE in the following ways:

[2318] 1. to securely control access to, and/or other usage of,confidential client records,

[2319] 2. to securely control access, distribution, and/or other rightsto documents and memoranda created at the law firm,

[2320] 3. to securely control access and other use of research materialsassociated with the case,

[2321] 4. to securely control access and other use, includingdistribution of records, documents, and notes associated with the case,

[2322] 5. to securely control how other firms in the litigation team mayuse, including change, briefs that have been distributed for comment andreview,

[2323] 6. to help manage client billing.

[2324] The law firm may also use VDE to electronically file briefs withthe court (presuming the court is also VDE capable) including providingsecure audit verification of the ID (e.g., digital signature) of filersand other information pertinent to said filing procedure.

[2325] In this example, the law firm receives in VDE content containersdocuments from their client's VDE installation secure subsystem(s).Alternatively, or in addition, the law firm may receive either physicaldocuments which may be scanned into electronic form, and/or they receiveelectronic documents which have not yet been placed in VDE containers.The electronic form of a document is stored as a VDE container (object)associated with the specific client and/or case. The VDE containermechanism supports a hierarchical ordering scheme for organizing filesand other information within a container; this mechanism may be used toorganize the electronic copies of the documents within a container, AVDE container is associated with specific access control information andrights that are described in one or more permissions control informationsets (PERCs) associated with that container. In this example, only thosemembers of the law firm who possess a VDE instance, an appropriate PERC,and the VDE object that contains the desired document, may use thedocument. Alternatively or in addition, a law firm member may use a VDEinstance which has been installed on the law firm's network server. Inthis case, the member must be identified by an appropriate PERC and haveaccess to the document containing VDE object (in order to use the serverVDE installation). Basic access control to electronic documents isenabled using the secure subsystem of one or more user VDEinstallations.

[2326] VDE may be used to provide basic usage control in several ways.First, it permits the “embedding” of multiple containers within a singleobject. Embedded objects permit the “nesting” of control structureswithin a container. VDE also extends usage control information to anarbitrary granular level (as opposed to a file based level provided bytraditional operating systems) and provides flexible control informationover any action associated with the information which can be describedas a VDE controlled process. For example, simple control information maybe associated with viewing the one or more portions of documents andadditional control information may be associated with editing, printingand copying the same and/or different one or more portions of these samedocuments.

[2327] In this example, a “client” container contains all documents thathave been provided by the client (documents received in other containerscan be securely extracted and embedded into the VDE client containerusing VDE extraction and embedding capabilities). Each document in thisexample is stored as an object within the parent, client VDE container.The “client” container also has several other objects embedded withinit; one for each attorney to store their client notes, one (or more) forresearch results and related information, and at least one for copies ofletters, work papers, and briefs that have been created by the law firm.The client container may also contain other information about theclient, including electronic records of billing; time, accounting, andpayments. Embedding VDE objects within a parent VDE content containerprovides a convenient way to securely categorize and/or store differentinformation that shares similar control information. All client provideddocuments may, for example, be subject to the same control structuresrelated to use and non-disclosure. Attorney notes may be subject tocontrol information, for example, their use may be limited to theattorney who created the notes and those attorneys to whom such creatingattorney expressly grants access rights. Embedded containers alsoprovide a convenient mechanism to control collections of dissimilarinformation. For example, the research object(s) may be stored in theform of (or were derived from) VDE “smart objects” that contain theresults of research performed by that object. Research results relatedto one aspect of the case retrieved from a VDE enabled LEXIS site mightbe encapsulated as one smart object; the results of another sessionrelated to another (or the same) aspect of the case may be encapsulatedas a different object. Smart objects are used in this example to helpshow that completely disparate and separately delivered controlinformation may be incorporated into a client container as desiredand/or required to enforce the rights of providers (such as contentowners).

[2328] Control structures may be employed to manage any variety ofdesired granularities and/or logical document content groupings; adocument, page, paragraph, topically related materials, etc. In thisexample, the following assumptions are made: client provided documentsare controlled at the page level, attorney notes are controlled at thedocument level on an attorney by attorney basis, court filings andbriefs are controlled at a document level, research information iscontrolled at whatever level the content provider specifies at the timethe research was performed, and certain highly confidential informationlocated in various of the above content may be identified as subject todisplay and adding comments only, and only by the lead partnerattorneys, with only the creator and/or embedder of a given piece ofcontent having the right to be otherwise used (printed, extracted,distributed, etc).

[2329] In general, container content in this example is controlled withrespect to distribution of rights. This control information areassociated at a document level for all internally generated documents,at a page level for client level documents, and at the level specifiedby the content provider for research documents.

[2330] VDE control information can be structured in either complex orsimple structures, depending on the participant's desires. In somecases, a VDE creator will apply a series of control structuredefinitions that they prefer to use (and that are supported by the VDEapplication managing the specification of rules and control information,either directly, or through the use of certified application compatibleVDE component assemblies.

[2331] In this example, the law firm sets up a standard VDE clientcontent container for a new client at the time they accept the case. Alaw firm VDE administrator would establish a VDE group for the newclient and add the VDE IDs of the attorneys at the firm that areauthorized to work on the case, as well as provide, if appropriate, oneor more user template applications. These templates provide, forexample, one or more user interfaces and associated control structuresfor selection by users of additional and/or alternative controlfunctions (if allowed by senior control information), entry of controlparameter data, and or performing user specific administrative tasks.The administrator uses a creation tool along with a predefined creationtemplate to create the container. This creation template specifies thedocument usage (including distribution control information) fordocuments as described above. Each electronic document from the client(including letters, memoranda, E-mail, spreadsheet, etc.) are then addedto the container as separate embedded objects. Each new object iscreated using a creation template that satisfies that the defaultcontrol structures specified with the container as required for each newobject of a given type.

[2332] As each attorney works on the case, they may enter notes into anobject stored within the client's VDE container. These notes may betaken using a VDE aware word processor already in use at the law firm.In this example, a VDE redirector handles the secure mapping of the wordprocessor file requests into the VDE container and its objects throughthe use of VDE control processes operating with one or more VDE PPEs.Attorney note objects are created using the default creation templatefor the document type with assistance from the attorney if the typecannot be automatically determined from the content. This permits VDE toautomatically detect and protect the notes at the predetermined level,e.g. document, page, paragraph.

[2333] Research can be automatically managed using VDE. Smart objectscan be, used to securely search out, pay for if necessary, and retrieveinformation from VDE enabled information resources on the informationhighway.

[2334] Examples of such resources might include LEXIS, Westlaw, andother related legal databases. Once the information is retrieved, it maybe securely embedded in the VDE content client container. If the smartobject still contains unreleased information, the entire smart objectmay be embedded in the client's VDE container. This places theunreleased information under double VDE control requirements: thoseassociated with releasing the information from smart object (such aspayment and/or auditing requirements) and those associated with accessto, or other usage of, client information of the specified type.

[2335] Briefs and other filings may be controlled in a manner similar tothat for attorney notes. The filings may be edited using the standardword processors in the law firm; with usage control structurescontrolling who may review, change, and/or add to the document (or, in amore sophisticated example, a certain portion of said document). VDE mayalso support electronic fling of briefs by providing a trusted sourcefor time/date stamping and validation of filed documents.

[2336] When the client and attorney want to exchange confidentialinformation over electronic mail or other means, VDE can play animportant role in ensuring that information exchanged under privilege,properly controlled, and not inappropriately released and/or otherwiseused. The materials (content) stored in a VDE content container objectwill normally be encrypted. Thus wrapped, a VDE object may bedistributed to the recipient without fear of unauthorized access and/orother use. The one or more authorized users who have received an objectare the only parties who may open that object and view and/or manipulateand/or otherwise modify its contents and VDE secure auditing ensures arecord of all such user content activities. VDE also permits therevocation of rights to use client/attorney privileged information ifsuch action becomes necessary, for example, after an administratorreview of user usage audit information.

[2337] Large Organization Example

[2338] In a somewhat more general example, suppose an organization(e.g., a corporation or government department) with thousands ofemployees and numerous offices disposed throughout a large geographicarea wishes to exercise control over distribution of information whichbelongs to said organization (or association). This information may takethe form of formal documents, electronic mail messages, text files,multimedia files, etc,, which collectively are referred to as“documents.”

[2339] Such documents may be handled by people (referred to as “users”)and/or by computers operating on behalf of users. The documents mayexist both in electronic form for storage and transmission and in paperform for manual handling.

[2340] These documents may originate wholly within the organization, ormay be created, in whole or in part, from information received fromoutside the organization. Authorized persons within the organization maychoose to release documents, in whole or in part, to entities outsidethe organization. Some such entities may also employ VDE 100 fordocument control, whereas others may not.

[2341] Document Control Policies

[2342] The organization as a whole may have a well-defined policy foraccess control to, and/or other usage control of documents. This policymay be based on a “lattice model” of information flow, in whichdocuments are characterized as having one or more hierarchical“classification” security attributes 9903 and zero or morenon-hierarchical “compartment” security attributes, all of whichtogether comprise a sensitivity security attribute.

[2343] The classification attributes may designate the overall level ofsensitivity of the document as an element of an ordered set. Forexample, the set “unclassified,” “confidential,” “secret,” “top secret”might be appropriate in a government setting, and the set “public,”“internal,” “confidential,” “registered confidential” might beappropriate in a corporate setting.

[2344] The compartment attributes may designate the document'sassociation with one or more specific activities within theorganization, such as departmental subdivisions (e.g., “research,”“development,” “marketing”) or specific projects within theorganization.

[2345] Each person using an electronic appliance 600 would be assigned,by an authorized user, a set of permitted sensitivity attributes todesignate those documents, or one or more portions of certain documenttypes, which could be processed in certain one or more ways, by theperson's electronic appliance. A document's sensitivity attribute wouldhave to belong to the user's set of permitted sensitivity values to beaccessible.

[2346] In addition, the organization may desire to permit users toexercise control over specific documents for which the user has somedefined responsibility. As an example, a user (the “originating user”)may wish to place an “originator controlled” (“ORCON”) restriction on acertain document, such that the document may be transmitted and usedonly by those specific other users whom he designates (and only incertain, expressly authorized ways). Such a restriction may be flexibleif the “distribution list” could be modified after the creation of thedocument, specifically in the event of someone requesting permissionfrom the originating user to transmit the document outside the originallist of authorized recipients. The originating user may wish to permitdistribution only to specific users, defined groups of users, definedgeographic areas, users authorized to act in specific organizationalroles, or a combination of any or all such attributes.

[2347] In this example, the organization may also desire to permit usersto define a weaker distribution restriction such that access to adocument is limited as above, but certain or all information within thedocument may be extracted and redistributed without further restrictionby the recipients.

[2348] The organization and/or originating users may wish to know towhat uses or geographic locations a document has been distributed. Theorganization may wish to know where documents with certain protectionattributes have been distributed, for example, based on geographicinformation stored in site configuration records and/or name servicesrecords.

[2349] A user may wish to request a “return receipt” for a distributeddocument, or may wish to receive some indication of how a document hasbeen handled by its recipients (e.g., whether it has been viewed,printed, edited and/or stored), for example, by specifying one or moreaudit requirements (or methods known to have audit requirements) in aPERC associated with such document(s).

[2350] User Environment

[2351] In an organization (or associateion) such as that describedabove, users may utilize a variety of electronic appliances 600 forprocessing and managing documents. This may include personal computers,both networked and otherwise, powerful single-user workstations, andservers or mainframe computers. To provide support for the controlinformation described in this example, each electronic appliance thatparticipates in use and management of VDE-protected documents may beenhanced with a VDE secure subsystem supporting an SPE 503 and/or HPE655.

[2352] In some organizations, where the threats to secure operation arerelatively low, an HPE 655 may suffice. In other organizations (e.g.,government defense), it may be necessary to employ an SPE 503 in allsituations where VDE-protected documents are processed. The choice ofenhancement environment and technology may be different in different ofthe organization. Even if different types of PPE 650 are used within anorganization to serve different requirements, they may be compatible andmay operate on the same types (or subsets of types) of documents.

[2353] Users may employ application programs that are customized tooperate in cooperation with the VDE for handling of VDE-protecteddocuments. Examples of this may include VDE-aware document viewers, VDEaware electronic mail systems, and similar applications. Those programsmay communicate with the PPE 650 component of a user's electronicappliance 600 to make VDE-protected documents available for use whilelimiting the extent to which their contents may be copied, stored,viewed, modified, and/or transmitted and/or otherwise furtherdistributed outside the specific electronic appliance.

[2354] Users may wish to employ commercial, off-the-shelf (“COTS”)operating systems and application programs to process the VDE-protecteddocuments. One approach to permit the use of COTS application programsand operating systems would be to allow such use only for documentswithout restrictions on redistribution. The standard VDE operatingsystem redirector would allow users to access VDE-protected documents ina manner equivalent to that for files. In such an approach, however, achain of control for metering and/or auditing use may be “broken” tosome extent at the point that the protected object was made available tothe COTS application. The fingerprinting (watermarking) techniques ofVDE may be used to facilitate further tracking of any releasedinformation.

[2355] A variety of techniques may be used to protect printing ofprotected documents, such as, for example: server-based decryptionengines, special fonts for “fingerprinting,” etc.

[2356] Another approach to supporting COTS software would use the VDEsoftware ruling on the user's electronic appliance to create one or more“virtual machine” environments in which COTS operating system andapplication programs may run, but from which no information may bepermanently stored or otherwise transmitted except under control of VDE.Such an environment would permit VDE to manage all VDE-protectedinformation, yet may permit unlimited use of COTS applications toprocess that information within the confines of a restrictedenvironment. The entire contents of such an environment could be treatedby VDE 100 as an extension to any VDE-protected documents read into theenvironment. Transmission of information out of the environment could begoverned by the same rules as the original document(s).

[2357] “Coarse-Grain” Control Capabilities

[2358] As mentioned above, an organization may employ VDE-enforcedcontrol capabilities to manage the security, distribution, integrity,and control of entire documents. Some examples of these capabilities mayinclude:

[2359] 1) A communication channel connecting two or more electronicappliances 600 may be assigned a set of permitted sensitivityattributes. Only documents whose sensitivity attributes belong to thisset would be permitted to be transmitted over the channel. This could beused to support the Device Labels requirement of the Trusted ComputerSystem Evaluation Criteria (TCSEC).

[2360] 2) A writable storage device (e.g., fixed disk, diskette, tapedrive, optical disk) connected to or incorporated in an electronicappliance 600 may be assigned a set of permitted sensitivity attributes.Only documents whose sensitivity attributes belong to this set would bepermitted to be stored on the device. This could be used to support theTCSEC Device Labels requirement.

[2361] 3) A document may have a list of users associated with itrepresenting the users who are permitted to “handle” the document. Thislist of users may represent, for example, the only users who may viewthe document, even if other users receive the document container, theycould not manipulate the contents. This could be used to support thestandard ORCON handling caveat.

[2362] 4) A document may have an attribute designating its originatorand requiring an explicit permission to be granted by an originatorbefore the document's content could be viewed. This request forpermission may be made at the time the document is accessed by a user,or, for example, at the time one user distributes the document toanother user. If permission is not granted, the document could not bemanipulated or otherwise used.

[2363] 5) A document may have an attribute requiring that each use ofthe document be reported to the document's originator. This may be usedby an originator to gauge the distribution of the document. Optionally,the report may be required to have been made successfully before any useof the document is permitted, to ensure that the use is known to thecontrolling party at the time of use. Alternatively, for example, thereport could be made in a deferred (“batch”) fashion.

[2364] 6) A document may have an attribute requiring that each use ofthe document be reported to a central document tracking clearinghouse.This could be used by the organization to track specific documents, toidentify documents used by any particular user and/or group of users totrack documents with specific attributes (e.g., sensitivity), etc.Optionally, for example, the report may be required to have been madesuccessfully before any use of the document is permitted.

[2365] 7) A VDE protected document may have an attribute requiring thateach use of the document generate a “return receipt,” to an originator.A person using the document may be required to answer specific questionsin order to generate a return receipt, for example by indicating why thedocument is of interest, or by indicating some knowledge of thedocument's contents (after reading it). This may be used as assurancethat the document had been handled by a person, not by any automatedsoftware mechanism.

[2366] 8) A VDE protected document's content may be made available to aVDE-unaware application program in such a way that it is uniquelyidentifiable (traceable) to a user who caused its release. Thus, if thereleased form of the document is further distributed, its origin couldbe determined. This may be done by employing VDE “fingerprinting” forcontent release. Similarly, a printed VDE protected document may bemarked in a similar, VDE fingerprinted unique way such that the personwho originally printed the document could be determined, even if copieshave since been made.

[2367] 9) Usage of VDE protected documents could be permitted undercontrol of budgets that limit (based on size, time of access, etc.)access or other usage of document content. This may help preventwholesale disclosure by limiting the number of VDE documents accessibleto an individual during a fixed time period. For example, one suchcontrol might permit a user, for some particular class of documents, toview at most 100 pages/day, but only print 10 pages/day and permitprinting only on weekdays between nine and five. As a further example, auser might be restricted to only a certain quantity of logicallyrelated, relatively “contiguous” and/or some other pattern (such aslimiting the use of a database's records based upon the quantity ofrecords that share a certain identifier in field) of VDE protecteddocument usage to identify, for example, the occurrence of one or moretypes of excessive database usage (under normal or any reasonablecircumstances). As a result, VDE content providers can restrict usage ofVDE content to acceptable usage characteristics and thwart and/oridentify (for example, by generating an exception report for a VDEadministrator or organization supervisor) user attempts toinappropriately use, for example, such an information database resource.

[2368] These control capabilities show some examples of how VDE can beused to provide a flexible, interactive environment for tracking andmanaging sensitive documents. Such an environment could directly tracethe flow of a document from person to person, by physical locations, byorganizations, etc. It would also permit specific questions to beanswered such as “what persons outside the R&D department have receivedany R&D-controlled document.” Because the control information is carriedwith each copy of a VDE protected document, and can ensure that centralregistries are updated and/or that originators are notified of documentuse, tracking can be prompt and accurate.

[2369] This contrasts with traditional means of tracking paperdocuments: typically, a paper-oriented system of manually collected andhandled receipts is used. Documents may be individually copy-numberedand signed for, but once distributed are not actively controlled. In atraditional paper-oriented system, it is virtually impossible todetermine the real locations of documents; what control can be assertedis possible only if all parties strictly follow the handling rules(which are at best inconvenient).

[2370] The situation is no better for processing documents within thecontext of ordinary computer and network systems. Although said systemscan enforce access control information based on user identity, and canprovide auditing mechanisms for tracking accesses to files, these arelow-level mechanisms that do not permit tracking or controlling the flowof content. In such systems, because document content can be freelycopied and manipulated, it is not possible to determine where documentcontent has gone, or where it came from. In addition, because thecontrol mechanisms in ordinary computer operating systems operate at alow level of abstraction, the entities they control are not necessarilythe same as those that are manipulated by users. This particularlycauses audit trails to be cluttered with voluminous informationdescribing uninteresting activities.

[2371] “Fine-Grain” Control Capabilities

[2372] In addition to controlling and managing entire documents, usersmay employ customized VDE-aware application software to control andmanage individual modifications to documents. Examples of thesecapabilities include the following:

[2373] 1) A VDE content user may be permitted to append furtherinformation to a VDE document to indicate a proposed alternativewording. This proposed alteration would be visible to all other users(in addition to the original text) of the document but would (forexample) be able to be incorporated into the actual text only by thedocument's owner.

[2374] 2) A group of VDE users could be permitted to modify one or moreparts of a document in such a way that each individual alteration wouldbe unambiguously traceable to the specific user who performed it. Therights to modify certain portions of a document, and the extension ofdiffering sets of rights to different users, allows an organization orsecure environment to provide differing permissions enabling differentrights to users of the same content.

[2375] 3) A group of users could create a VDE document incrementally, bybuilding it from individual contributions. These contributions would bebound together within a single controlled document, but each would beindividually identified, for example, through their incorporation in VDEcontent containers as embedded container objects.

[2376] 4) VDE control and management capabilities could be used to trackactivities related to individual document areas, for instance recordinghow many times each section of a document was viewed.

[2377] Example—VDE Protected Content Repository

[2378] As the “Digital Highway” emerges, there is increased discussionconcerning the distribution of content across networks and, inparticular, public networks such as the Internet. Content may be madeavailable across public networks in several ways including:

[2379] “mailing” content to a user in response to a request or advancepurchase (sending a token representing the commitment of electronicfunds or credit to purchase an item);

[2380] supporting content downloadable from an organization's owncontent repository, such a repository comprising, for example, a storeof products (such as software programs) and/or a store of informationresources, normally organized into one or more databases; and

[2381] supporting a public repository into which other parties candeposit their products for redistribution to customers (normally bymaking electronic copies for distribution to a customer in response to arequest).

[2382] One possible arrangement of VDE nodes involves use of one or more“repositories.” A repository, for example, may serve as a location fromwhich VDE participants may retrieve VDE content containers. In thiscase, VDE users may make use of a network to gain access to a “server”system that allows one or more VDE users to access an object repositorycontaining VDE content containers.

[2383] Some VDE participants may create or provide content and/or VDEcontent container objects, and then store content and/or content objectsat a repository so that other participants may access such content froma known and/or efficiently organized (for retrieval) location. Forexample, a VDE repository (portion of a VDE repository, multiple VDErepositories, and/or providers of content to such repositories) mayadvertise the availability of certain types of VDE protected content bysending out email to a list of network users. If the network users havesecure VDE subsystems in their electronic appliances, they may thenchoose to access such a repository directly, or through one or moresmart agents and, using an application program for example, browse(and/or electronically search) through the offerings of VDE managedcontent available at the repository, download desirable VDE contentcontainers, and make use of such containers. If the repository issuccessful in attracting users who have an interest in such content, VDEcontent providers may determine that such a repository is a desirablelocation(s) to make their content available for easy access by users. Ifa repository, such as CompuServe, stores content in non-encrypted(plaintext) form, it may encrypt “outgoing” content on an “as needed”basis through placing such content in VDE content containers withdesired control information, and may employ VDE secure communicationstechniques for content communication to VDE participants.

[2384] VDE repositories may also offer other VDE services. For example,a repository may choose to offer financial services in the form ofcredit from the repository that may be used to pay fees associated withuse of VDE objects obtained from the repository. Alternatively or inaddition, a VDE repository may perform audit information clearinghouseservices on behalf of VDE creators or other participants (e.g.distributors, redistributors, client administrators, etc.) for usageinformation reported by VDE users. Such services may include analyzingsuch usage information, creating reports, collecting payments, etc.

[2385] A “full service” VDE repository may be very attractive to bothproviders and users of VDE managed content. Providers of VDE managedcontent may desire to place their content in a location that is wellknown to users, offers credit, and/or performs audit services for them.In this case, providers may be able to focus on creating content, ratherthan managing the administrative processes associated with makingcontent available in a “retail” fashion, collecting audit informationfrom many VDE users, sending and receiving bills and payments, etc. VDEusers may find the convenience of a single location (or an integratedarrangement of repositories) appealing as they are attempting to locatecontent of interest. In addition, a full service VDE repository mayserve as a single location for the reporting of usage informationgenerated as a consequence of their use of VDE managed content receivedfrom a VDE repository and/or, for example, receiving updated software(e.g. VDE-aware applications, load modules, component assemblies, nonVDE-aware applications, etc.) VDE repository services may be employed inconjunction with VDE content delivery by broadcast and/or on physicalmedia, such as CD-ROM, to constitute an integrated array of contentresources that may be browsed, searched, and/or filtered, asappropriate, to fulfill the content needs of VDE users.

[2386] A public repository system may be established and maintained as anon-profit or for-profit service. An organization offering the servicemay charge a service fee, for example, on a per transaction basis and/oras a percentage of the payments by, and/or cost of, the content tousers. A repository service may supply VDE authoring tools to contentcreators, publishers, distributors, and/or value adding providers suchthat they may apply rules and controls that define some or all of theguidelines managing use of their content and so that they may place suchcontent into VDE content container objects.

[2387] A repository may be maintained at one location or may bedistributed across a variety of electronic appliances, such as a varietyof servers (e.g. video servers, etc.) which may be at differentlocations but nonetheless constitute a single resource. A VDE repositoryarrangement may employ VDE secure communications and VDE node securesubsystems (“protected processing environments”). The content comprisinga given collection or unit of information desired by a user may bespread across a variety of physical locations. For example, contentrepresenting a company's closing stock price and the activity (bids,lows, highs, etc.) for the stock might be located at a World Wide Webserver in New York, and content representing an analysis of the company(such as a discussions of the company's history, personnel, products,markets, and/or competitors) might be located on a server in Dallas. Thecontent might be stored using VDE mechanisms to secure and audit use.The content might be maintained in clear form if sufficient other formsof security are available at such one or more of sites (e.g. physicalsecurity, password, protected operating system, data encryption, orother techniques adequate for a certain content type). In the latterinstances, content may be at least in part encrypted and placed in VDEcontainers as it streams out of a repository so as to enable securecommunication and subsequent VDE usage control and usage consequencemanagement.

[2388] A user might request information related to such a companyincluding stock and other information. This request might, for example,be routed first through a directory or a more sophisticated databasearrangement located in Boston. This arrangement might contain pointersto, and retrieve content from, both the New York and Dallasrepositories. This information content may, for example, be routeddirectly to the user in two containers (e.g. such as a VDE contentcontainer object from Dallas and a VDE content container object from NewYork). These two containers may form two VDE objects within a single VDEcontainer (which may contain two content objects containing therespective pieces of content from Dallas and New York) when processed bythe user's electronic appliance. Alternatively, such objects might beintegrated together to form a single VDE container in Boston so that theinformation can be delivered to the user within a single container tosimplify registration and control at the user's site. The informationcontent from both locations may be stored as separate informationobjects or they may be joined into a single, integrated informationobject (certain fields and/or categories in an information form ortemplate may be filled in by one resource and other fields and/orcategories may be filled by information provided by a differentresource). A distributed database may manage such a distributedrepository resource environment and use VDE to secure the storing,communicating, auditing, and/or use of information through VDE'selectronic enforcement of VDE controls. VDE may then be used to provideboth consistent content containers and content control services.

[2389] An example of one possible repository arrangement 3300 is shownin FIG. 78. In this example, a repository 3302 is connected to a network3304 that allows authors 3306A, 3306B, 3306C, and 3306D; a publisher3308; and one or more end users 3310 to communicate with the repository3302 and with each other. A second network 3312 allows the publisher3308, authors 3306E and 3306F, an editor 3314, and a librarian 3316 tocommunicate with each other and with a local repository 3318. Thepublisher 3308 is also directly connected to author 3306E. In thisexample, the authors 3306 and publisher 3308 connect to the repository3302 in order to place their content into an environment in which endusers 3310 will be able to gain access to a broad selection of contentfrom a common location.

[2390] In this example, the repository has two major functional areas: acontent system 3302A and a clearinghouse system 3302B. The contentsystem 3302A is comprised of a user/author registration system 3320, acontent catalog 3322, a search mechanism 3324, content storage 3326,content references 3328, and a shipping system 3330 comprised of acontrols packager 3322, a container packager 3334, and a transactionsystem 3336. The clearinghouse system 3302B is comprised of auser/author registration system 3338; template libraries 3340; a controlstructure library 3342; a disbursement system 3344; an authorizationsystem 3346 comprised of a financial system 3348 and a content system3350; a billing system 3352 comprised of a paper system 3354, a creditcard system 3356, and an electronic funds transfer (EFT) system 3358;and an audit system 3360 comprised of a receipt system 3362, a responsesystem 3364, a transaction system 3366, and an analysis system 3368.

[2391] In this example, author 3306A creates content in electronic formthat she intends to make broadly available to many end users 3310, andto protect her rights through use of VDE. Author 3306A transmits amessage to the repository 3302 indicating her desire to register withthe repository to distribute her content. In response to this message,the user/author registration system 3320 of the content system 3302A,and the user author registration system 3338 of the clearinghouse system3302B transmit requests for registration information to author 3306Ausing the network 3304. These requests may be made in an on-lineinteractive mode; or they may be transmitted in a batch to author 3306Awho then completes the requested information and transmits it as a batchto the repository 3302; or some aspects may be handled on-line (such asbasic identifying information) and other information may be exchanged ina batch mode.

[2392] Registration information related to the content system 3302A may,for example, include:

[2393] a request that Author 3306A provide information concerning thetypes and/or categories of content proposed for storage and access usingthe repository,

[2394] the form of abstract and/or other identifying informationrequired by the repository—in addition to providing author 3306A with anopportunity to indicate whether or not author 3306A generally includesother information with content submissions (such as promotionalmaterials, detailed information regarding the format of submittedcontent, any equipment requirements that should or must be met forpotential users of submitted content to successfully exploit its value,etc.),

[2395] requests for information from author 3306A concerning where thecontent is to be located (stored at the repository, stored at author3306A's location, stored elsewhere, or some combination of locations),

[2396] what general search characteristics should be associated withcontent submissions (e.g. whether abstracts should be automaticallyindexed for searches by users of the repository, the manner in whichcontent titles, abstracts, promotional materials, relevant dates, namesof performers and/or authors, or other information related to contentsubmissions may or should be used in lists of types of content and/or inresponse to searches, etc.), and/or

[2397] how content that is stored at and/or passed through therepository should be shipped (including any container criteria,encryption requirements, transaction requirements related to contenttransmissions, other control criteria, etc.)

[2398] The information requested from author 3306A by the user/authorregistration system of the clearinghouse may, for example, consist of:

[2399] VDE templates that author 3306A may or must make use of in orderto correctly format control information such that, for example, theaudit system 3360 of the clearinghouse system 3302B is properlyauthorized to receive and/or process usage information related tocontent submitted by author 3306A,

[2400] VDE control information available from the clearinghouse 3302Bthat may or must be used by author 3306A (and/or included by reference)in some or all of the VDE component assemblies created and/or used byauthor 3306A associated with submitted content,

[2401] the manner in which disbursement of any funds associated withusage of content provided by, passed through, or collected by therepository clearinghouse system 3302B should be made,

[2402] the form and/or criteria of authorizations to use submittedcontent and/or financial transactions associated with content,

[2403] the acceptable forms of billing for use of content and/orinformation associated with content (such as analysis reports that maybe used by others),

[2404] how VDE generated audit information should be received,

[2405] how responses to requests from users should be managed,

[2406] how transactions associated with the receipt of audit informationshould be formatted and authorized,

[2407] how and what forms of analysis should be performed on usageinformation, and/or

[2408] under what circumstances (if any) usage information and/oranalysis results derived from VDE controlled content usage informationshould be managed (including to whom they may or must be delivered, theform of delivery, any control information hat may be associated with useof such information, etc.)

[2409] The repository 3302 receives the completed registrationinformation from author 3306A and uses this information to build anaccount profile for author 3306A. In addition, software associated withthe authoring process may be transmitted to author 3306A. This softwaremay, for example, allow author 3306A to place content into a VDE contentcontainer with appropriate controls in such a way that many of thedecisions associated with creating such containers are madeautomatically to reflect the use of the repository 3302 as a contentsystem and/or a clearinghouse system (for example, the location ofcontent, the party to contact for updates to content and/or controlsassociated with content, the party or parties to whom audit informationmay and/or must be transmitted and the pathways for such communication,the character of audit information that is collected during usage, theforms of payment that are acceptable for use of content, the frequencyof audit transmissions required, the frequency of billing, the form ofabstract and/or other identifying information associated with content,the nature of at least a portion of content usage control information,etc.)

[2410] Author 3306A makes use of a VDE authoring application to specifythe controls and the content that she desires to place within a VDEcontent container, and produces such a container in accordance with anyrequirements of the repository 3302. Such a VDE authoring applicationmay be, for example, an application provided by the repository 3302which can help ensure adherence to repository content controlrequirements such as the inclusion of one or more types of componentassemblies or other VDE control structures and/or required parameterdata, an application received from another party, and/or an applicationcreated by author 3306A in whole or in part. Author 3306A then uses thenetwork 3304 to transmit the container and any deviations from author3306A's account profile that may relate to such content to therepository 3302. The repository 3302 receives the submitted content, andthen—in accordance with any account profile requirements, deviationsand/or desired options in this example—makes a determination as towhether the content was produced within the boundaries of any contentand/or control information requirements of the repository and thereforeshould be placed within content storage or referenced by a locationpointer or the like. In addition to placing the submitted content intocontent storage or referencing such content's location, the repository3302 may also make note of characteristics associated with suchsubmitted content in the search mechanism 3324, content references 3328,the shipping system 3330, and/or the relevant systems of theclearinghouse system 3302B related to templates and control structures,authorizations, billing and/or payments, disbursements, and/or audits ofusage information.

[2411] During an authoring process, author 3306A may make use of VDEtemplates. Such templates may be used as an aspect of a VDE authoringapplication. For example, such templates may be used in the constructionof a container as described above. Alternatively or in addition, suchtemplates may also be used when submitted content is received by therepository 3302. References to such templates may be incorporated byauthor 3306A as an aspect of constructing a container for submittedcontent (in this sense the container delivered to the repository may bein some respects “incomplete” until the repository “completes” thecontainer through use of indicated templates). Such references may berequired for use by the repository 3302 (for example, to place VDEcontrol information in place to fulfill an aspect of the repository'sbusiness or security models such as one or more map tables correspondingto elements of content necessary for interacting with other VDE controlstructures to accommodate certain metering, billing, budgeting, and/orother usage and/or distribution related controls of the repository).

[2412] For example, if content submitted by author 3306A consists of aperiodical publication, a template delivered to the author by therepository 3302 when the author registers at the repository may be usedas an aspect of an authoring application manipulated by the author increating a VDE content container for such a periodical. Alternatively orin addition, a template designed for use with periodical publicationsmay be resident at the repository 3302, and such a template may be usedby the repository to define, in whole or in part, control structuresassociated with such a container. For example, a VDE template designedto assist in formulating control structures for periodical publicationsmight indicate (among other things) that:

[2413] usage controls should include a meter method that records eacharticle within a publication that a user opens,

[2414] a certain flat rate fee should apply to opening the periodicalregardless of the number of articles opened, and/or

[2415] a record should be maintained of every advertisement that isviewed by a user.

[2416] If content is maintained in a known and/or identifiable formatsuch a template may be used during initial construction of a containerwithout author 3306A's intervention to identify any map tables that maybe required to support such recording and billing actions. If such a VDEtemplate is unavailable to author 3306A, she may choose to indicate thatthe container submitted should be reconstructed (e.g. augmented) by therepository to include the VDE control information specified in a certaintemplate or class of templates. If the format of the content is knownand/or identifiable by the repository, the repository may be able toreconstruct (or “complete”) such a container automatically.

[2417] One factor in a potentially ongoing financial relationshipbetween the repository and author 3306A may relate to usage of submittedcontent by end users 3310. For example, author 3306A may negotiate anarrangement with the repository wherein the repository is authorized tokeep 20% of the total revenues generated from end users 3310 in exchangefor maintaining the repository services (e.g. making content availableto end users 3310, providing electronic credit, performing billingactivities, collecting fees, etc.) A financial relationship may berecorded in control structures in flexible and configurable ways. Forexample, the financial relationship described above could be created ina VDE container and/or installation control structure devised by author3306A to reflect author 3306A's financial requirements and the need fora 20% split in revenue with the repository wherein all billingactivities related to usage of submitted content could be processed bythe repository, and control structures representing reciprocal methodsassociated with various component assemblies required for use of author3306A's submitted content could be used to calculate the 20% ofrevenues. Alternatively, the repository may independently and securelyadd and/or modify control structures originating from author 3306A inorder to reflect an increase in price. Under some circumstances, author3306A may not be directly involved (or have any knowledge of) the actualprice that the repository charges for usage activities, and may concernherself only with the amount of revenue and character of usage analysisinformation that she requires for her own purposes, which she specifiesin VDE control information which governs the use, and consequences ofuse, of VDE controlled content.

[2418] Another aspect of the relationship between authors and therepository may involve the character of transaction recordingrequirements associated with delivery of VDE controlled content andreceipt of VDE controlled content usage audit information. For example,author 3306A may require that the repository make a record of each userthat receives a copy of content from the repository. Author 3306A mayfurther require collection of information regarding the circumstances ofdelivery of content to such users (e.g. time, date, etc.) In addition,the repository may elect to perform such transactions for use internally(e.g. to determine patterns of usage to optimize systems, detect fraud,etc.)

[2419] In addition to recording information regarding delivery of suchVDE controlled content, author 3306A may have required or requested therepository to perform certain VDE container related processes. Forexample, author 3306A may want differing abstract and/or otherdescriptive information delivered to different classes of users. Inaddition, author 3306A may wish to deliver promotional materials in thesame container as submitted content depending on, for example, thecharacter of usage exhibited by a particular user (e.g. whether the userhas ever received content from author 3306A, whether the user is aregular subscriber to author 3306A's materials, and/or other patternsthat may be relevant to author 3306A and/or the end user that are usedto help determine the mix of promotional materials delivered to acertain VDE content end user.) In another example, author 3306A mayrequire that VDE fingerprinting be performed on such content prior totransmission of content to an end user.

[2420] In addition to the form and/or character of content shipped to anend user, authors may also require certain encryption related processesto be performed by the repository as an aspect of delivering content.For example, author 3306A may have required that the repository encrypteach copy of shipped content using a different encryption key or keys inorder to help maintain greater protection for content (e.g. in case anencryption key was “cracked” or inadvertently disclosed, the “damage”could be limited to the portion(s) of that specific copy of a certaincontent deliverable). In another example, encryption functions mayinclude the need to use entirely different encryption algorithms and/ortechniques in order to fulfill circumstantial requirements (e.g. tocomply with export restrictions). In a further example, encryptionrelated processes may include changing the encryption techniques and/oralgorithms based on the level of trustedness and/or tamper resistance ofthe VDE site to which content is delivered.

[2421] In addition to transaction information gathered when content isshipped from a VDE repository to an end user, the repository may berequired to keep transaction information related to the receipt of usageinformation, requests, and/or responses to and/or from end users 3310.For example, author 3306A may require the repository to keep a log ofsome or all connections made by end users 3310 related to transmissionsand or reception of information related to the use of author 3306A'scontent (e.g. end user reporting of audit information, end user requestsfor additional permissions information, etc.)

[2422] Some VDE managed content provided to end users 3310 through therepository may be stored in content storage. Other information may bestored elsewhere, and be referenced through the content references. Inthe case where content references are used, the repository may managethe user interactions in such a manner that all repository content,whether stored in content storage or elsewhere (such as at anothersite), is presented for selection by end users 3310 in a uniform way,such as, for example, a consistent or the same user interface. If an enduser requests delivery of content that is not stored in content storage,the VDE repository may locate the actual storage site for the contentusing information stored in content references (e.g. the network addresswhere the content may be located, a URL, a filesystem reference, etc.)After the content is located, the content may be transmitted across thenetwork to the repository or it may be delivered directly from where itis stored to the requesting end user. In some circumstances (e.g. whencontainer modification is required, when encryption must be changed, iffinancial transactions are required prior to release, etc.), furtherprocessing may be required by the repository in order to prepare suchVDE managed content and/or VDE content container for transmission to anend user.

[2423] In order to provide a manageable user interface to the contentavailable to VDE repository end users 3310 and to provide administrativeinformation used in the determination of control information packaged inVDE content containers shipped to end users 3310, the repository in thisexample includes a content catalog 3322. This catalog is used to recordinformation related to the VDE content in content storage, and/orcontent available through the repository reflected in contentreferences. The content catalog 3322 may consist of titles of content,abstracts, and other identifying information. In addition, the catalogmay also indicate the forms of electronic agreement and/or agreement VDEtemplate applications (offering optional, selectable control structuresand/or one or more opportunities to provide related parameter data) thatare available to end users 3310 through the repository for given piecesof content in deciding, for example, options and/or requirements for:what type(s) of information is recorded during such content's use, thecharge for certain content usage activities, differences in chargesbased on whether or not certain usage information is recorded and/ormade available to the repository and/or content provider, theredistribution rights associated with such content, the reportingfrequency for audit transmissions, the forms of credit and/or currencythat may be used to pay certain fees associated with use of suchcontent, discounts related to certain volumes of usage, discountsavailable due to the presence of rights associated with other contentfrom the same and/or different content providers, sales, etc.Furthermore, a VDE repository content catalog 3322 may indicate some orall of the component assemblies that are required in order to make useof content such that the end user's system and the repository canexchange messages to help ensure that any necessary VDE componentassemblies or other VDE control information is identified, and ifnecessary and authorized, are delivered along with such content to theend user (rather than, for example, being requested later after theirabsence has been detected during a registration and/or use attempt).

[2424] In order to make use of the VDE repository in this example, anend user must register with the repository. In a manner similar to thatindicated above in the case of an author, a VDE end user transmits amessage from her VDE installation to the repository across the networkindicating that she wishes to make use of the services provided by therepository (e.g. access content stored at and/or referenced by therepository, use credit provided by the repository, etc.) In response tothis message, the user/author registration systems of the content system3302A and the clearinghouse system 3302B of the repository transmitrequests for information from the end user (e.g. in an on-line and/orbatch interaction). The information requested by the user/authorregistration system of the content system 3302A may include type(s) ofcontent that the user wishes to access, the characteristics of theuser's electronic appliance 600, etc. The information requested by theuser/author registration system of the clearinghouse system 3302B mayinclude whether the user wishes to establish a credit account with theclearinghouse system 3302B, what other forms of credit the user may wishto use for billing purposes, what other clearinghouses may be used bythe end user in the course of interacting with content obtained from therepository, any general rules that the user has established regardingtheir preferences for release and handling of usage analysisinformation, etc. Once the end user has completed the registrationinformation and transmitted it to the repository, the repository mayconstruct an account profile for the user. In this example, suchrequests and responses are handled by secure VDE communications betweensecure VDE subsystems of both sending and receiving parties.

[2425] In order to make use of the repository, the end user may operateapplication software. In this example, the end user may either make useof a standard application program (e.g. a World Wide Web browser such asMosaic), or they may make use of application software provided by therepository after completion of the registration process. If the end userchooses to make use of the application software provided by therepository, they may be able to avoid certain complexities ofinteraction that may occur if a standard package is used. Althoughstandardized packages are often relatively easy to use, a customizedpackage that incorporates VDE aware functionality may provide an easierto use interface for a user. In addition, certain characteristics of therepository may be built in to the interface to simplify use of theservices (e.g. similar to the application programs provided by AmericaOnline).

[2426] The end user may connect to the repository using the network. Inthis example, after the user connects to the repository, anauthentication process will occur. This process can either be directedby the user (e.g. through use of a login and password protocol) or maybe established by the end user's electronic appliance secure subsystemsinteracting with a repository electronic appliance in a VDEauthentication. In either event, the repository and the user mustinitially ensure that they are connected to the correct other party. Inthis example, if secured information will flow between the parties, aVDE secured authentication must occur, and a secure session must beestablished. On the other hand, if the information to be exchanged hasalready been secured and/or is available without authentication (e.g.certain catalog information, containers that have already been encryptedand do not require special handling, etc.), the “weaker” form oflogin/password may be used.

[2427] Once an end user has connected to the VDE repository andauthentication has occurred, the user may begin manipulating anddirecting their user interface software to browse through a repositorycontent catalog 3322 (e.g. lists of publications, software, games,movies, etc.), use the search mechanism to help locate content ofinterest, schedule content for delivery, make inquiries of accountstatus, availability of usage analysis information, billing information,registration and account profile information, etc. If a user isconnecting to obtain content, the usage requirements for that contentmay be delivered to them. If the user is connecting to deliver usageinformation to the repository, information related to that transmissionmay be delivered to them. Some of these processes are described in moredetail below

[2428] In this example, when an end user requests content from the VDErepository (e.g. by selecting from a menu of available options), thecontent system 3302A locates the content either in the contentreferences and/or in content storage. The content system 3302A may thenrefer to information stored in the content catalog 3322, the end user'saccount profile, and/or the author's account profile to determine theprecise nature of container format and/or control information that maybe required to create a VDE content container to fulfill the end user'srequest. The shipping system then accesses the clearinghouse system3302B to gather any necessary additional control structures to includewith the container, to determine any characteristics of the author'sand/or end user's account profiles that may influence either thetransaction(s) associated with delivering the content to the end user orwith whether the transaction may be processed. If the transaction isauthorized, and all elements necessary for the container are available,the controls packager forms a package of control information appropriatefor this request by this end user, and the container packager takes thispackage of control information and the content and forms an appropriatecontainer (including any permissions that may be codeliverable with thecontainer, incorporating any encryption requirements, etc.) If requiredby the repository or the author's account profile, transactions relatedto delivery of content are recorded by the transaction system of theshipping system. When the container and any transactions related todelivery have been completed, the container is transmitted across thenetwork to the end user.

[2429] An end user may make use of credit and/or currency securelystored within the end user's VDE installation secure subsystem to payfor charges related to use of VDE content received from the repository,and/or the user may maintain a secure credit and/or currency accountremotely at the repository, including a “virtual” repository wherepayment is made for the receipt of such content by an end user. Thislater approach may provide greater assurance for payment to therepository and/or content providers particularly if the end user hasonly an HPE based secure subsystem. If an end user electronic creditand/or currency account is maintained at the repository in this example,charges are made to said account based on end user receipt of contentfrom the repository. Further charges to such a remote end user accountmay be made based on end user usage of such received content and basedupon content usage information communicated to the repositoryclearinghouse system 3302B.

[2430] In this example, if an end user does not have a relationshipestablished with a financial provider (who has authorized the contentproviders whose content may be obtained through use of the repository tomake use of their currency and/or credit to pay for any usage feesassociated with such provider's content) and/or if an end user desires anew source of such credit, the end user may request credit from therepository clearinghouse system 3302B. If an end user is approved forcredit, the repository may extend credit in the form of credit amounts(e.g. recorded in one or more UDEs) associated with a budget methodmanaged by the repository. Periodically, usage information associatedwith such a budget method is transmitted by the end user to the auditsystem of the repository. After such a transmission (but potentiallybefore the connection is terminated), an amount owing is recorded forprocessing by the billing system, and in accordance with therepository's business practices, the amount of credit available for useby the end user may be replenished in the same or subsequenttransmission. In this example, the clearinghouse of the repositorysupports a billing system with a paper system for resolving amounts owedthrough the mail, a credit card system for resolving amounts owedthrough charges to one or more credit cards, and an electronic fundstransfer system for resolving such amounts through direct debits to abank account. The repository may automatically make payments determinedby the disbursement system for monies owed to authors through use ofsimilar means. Additional detail regarding the audit process is providedbelow.

[2431] As indicated above, end users 3310 in this example willperiodically contact the VDE repository to transmit content usageinformation (e.g. related to consumption of budget, recording of otherusage activities, etc.), replenish their budgets, modify their accountprofile, access usage analysis information, and perform otheradministrative and information exchange activities. In some cases, anend user may wish to contact the repository to obtain additional controlstructures. For example, if an end user has requested and obtained a VDEcontent container from the repository, that container is typicallyshipped to the end user along with control structures appropriate to thecontent, the author's requirements and account profile, the end user'saccount profile, the content catalog 3322, and/or the circumstances ofthe delivery (e.g. the first delivery from a particular author, asubscription, a marketing promotion, presence and/or absence of certainadvertising materials, requests formulated on behalf of the user by theuser's local VDE instance, etc.) Even though, in this example, therepository may have attempted to deliver all relevant controlstructures, some containers may include controls structures that allowfor options that the end user did not anticipate exercising (and theother criteria did not automatically select for inclusion in thecontainer) that the end user nonetheless determines that they would liketo exercise. In this case, the end user may wish to contact therepository and request any additional control information (including,for example, control structures) that they will need in order to makeuse of the content under such option.

[2432] For example, if an end user has obtained a VDE content containerwith an overall control structure that includes an option that recordsof the number of times that certain types of accesses are made to thecontainer and further bases usage fees on the number of such accesses,and another option within the overall control structure allows the enduser to base the fees paid for access to a particular container based onthe length of time spent using the content of the container, and the enduser did not originally receive controls that would support this latterform of usage, the repository may deliver such controls at a later timeand when requested by the user. In another example, an author may havemade changes to their control structures (e.g. to reflect a sale, a newdiscounting model, a modified business strategy, etc.) which a user mayor must receive in order to use the content container with the changedcontrol structures. For example, one or more control structuresassociated with a certain VDE content container may require a “refresh”for continued authorization to employ such structures, or the controlstructures may expire. This allows (if desired) a VDE content providerto periodically modify and/or add to VDE control information at an enduser's site (employing the local VDE secure subsystem).

[2433] Audit information (related to usage of content received from therepository) in this example is securely received from end users 3310 bythe receipt system 3362 of the clearinghouse. As indicated above, thissystem may process the audit information and pass some or all of theoutput of such a process to the billing system and/or transmit suchoutput to appropriate content authors. Such passing of audit informationemploys secure VDE pathway of reporting information handling techniques.Audit information may also be passed to the analysis system in order toproduce analysis results related to end user content usage for use bythe end user, the repository, third party market researchers, and/or oneor more authors. Analysis results may be based on a single audittransmission, a portion of an audit transmission, a collection of audittransmissions from a single end user and/or multiple end users 3310, orsome combination of audit transmissions based on the subject of analysis(e.g. usage patterns for a given content element or collection ofelements, usage of certain categories of content, payment histories,demographic usage patterns, etc. The response system 3364 is used tosend information to the end user to, for example, replenish a budget,deliver usage controls, update permissions information, and to transmitcertain other information and/or messages requested and/or required byan end user in the course of their interaction with the clearinghouse.During the course of an end user's connections and transmissions to andfrom the clearinghouse, certain transactions (e.g. time, date, and/orpurpose of a connection and/or transmission) may be recorded by thetransaction system of the audit system to reflect requirements of therepository and/or authors.

[2434] Certain audit information may be transmitted to authors. Forexample, author 3306A may require that certain information gathered froman end user be transmitted to author 3306A with no processing by theaudit system. In this case, the fact of the transmission may be recordedby the audit system, but author 3306A may have elected to perform theirown usage analysis rather than (or in addition to) permitting therepository to access, otherwise process and/or otherwise use thisinformation. The repository in this example may provide author 3306Awith some of the usage information related to the repository's budgetmethod received from one or more end users 3310 and generated by thepayment of fees associated with such users' usage of content provided byauthor 3306A. In this case, author 3306A may be able to compare certainusage information related to content with the usage information relatedto the repository's budget method for the content to analyze patterns ofusage (e.g. to analyze usage in light of fees, detect possible fraud,generate user profile information, etc.) Any usage fees collected by theclearinghouse associated with author 3306A's content that are due toauthor 3306A will be determined by the disbursement system of theclearinghouse. The disbursement system may include usage information (incomplete or summary form) with any payments to author 3306A resultingfrom such a determination. Such payments and information reporting maybe an entirely automated sequence of processes occurring within the VDEpathway from end user VDE secure subsystems, to the clearinghouse securesubsystem, to the author's secure subsystem.

[2435] In this example, end users 3310 may transmit VDE permissionsand/or other control information to the repository 3302 permittingand/or denying access to usage information collected by the audit systemfor use by the analysis system. This, in part, may help ensure enduser's privacy rights as it relates to the usage of such information.Some containers may require, as an aspect of their control structures,that an end user make usage information available for analysis purposes.Other containers may give an end user the option of either allowing theusage information to be used for analysis, or denying some or all suchuses of such information. Some users may elect to allow analysis ofcertain information, and deny this permission for other information. Endusers 3310 in this example may, for example, elect to limit thegranularity of information that may be used for analysis purposes (e.g.an end user may allow analysis of the number of movies viewed in a timeperiod but disallow use of specific titles, an end user may allowrelease of their ZIP code for demographic analysis, but disallow use oftheir name and address, etc.) Authors and/or the repository 3302 may,for example, choose to charge end users 3310 smaller fees if they agreeto release certain usage information for analysis purposes.

[2436] In this example, the repository 3302 may receive content producedby more than one author. For example, author B, author C, and author Dmay each create portions of content that will be delivered to end users3310 in a single container. For example, author B may produce areference work. Author C may produce a commentary on author B'sreference work, and author D may produce a set of illustrations forauthor B's reference work and author C's commentary. Author B maycollect together author C's and author D's content and add furthercontent (e.g. the reference work described above) and include suchcontent in a single container which is then transmitted to therepository 3302. Alternatively, each of the authors may transmit theirworks to the repository 3302 independently, with an indication that atemplate should be used to combine their respective works prior toshipping a container to an end user. Still alternatively, a containerreflecting the overall content structure may be transmitted to therepository 3302 and some or all of the content may be referenced in thecontent references rather than delivered to the repository 3302 forstorage in content storage.

[2437] When an end user makes use of container content, their contentusage information may, for example, be segregated in accordance withcontrol structures that organize usage information based at least inpart on the author who created that segment. Alternatively, the authorsand/or the VDE repository 3302 may negotiate one or more othertechniques for securely dividing and/or sharing usage information inaccordance with VDE control information. Furthermore, control structuresassociated with a container may implement models that differentiate anyusage fees associated with portions of content based on usage ofparticular portions, overall usage of the container, particular patternsof usage, or other mechanism negotiated (or otherwise agreed to) by theauthors. Reports of usage information, analysis results, disbursements,and other clearinghouse processes may also be generated in a manner thatreflects agreements reached by repository 3302 participants (authors,end users 3310 and/or the repository 3302) with respect to suchprocesses. These agreements may be the result of a VDE controlinformation negotiation amongst these participants.

[2438] In this example, one type of author is a publisher 3308. Thepublisher 3308 in this example communicates over an “internal” networkwith a VDE based local repository 3302 and over the network describedabove with the public repository 3302. The publisher 3308 may create orotherwise provide content and/or VDE control structure templates thatare delivered to the local repository 3302 for use by other participantswho have access to the “internal” network. These templates may be usedto describe the structure of containers, and may further describe whomin the publisher 3308's organization may take which actions with respectto the content created within the organization related to publicationfor delivery to (and/or referencing by) the repository 3302. Forexample, the publisher 3308 may decide (and control by use of saidtemple) that a periodical publication will have a certain format withrespect to the structure of its content and the types of informationthat may be included (e.g. text, graphics, multimedia presentations,advertisements, etc.), the relative location and/or order ofpresentation of its content, the length of certain segments, etc.Furthermore, the publisher 3308 may, for example, determine (throughdistribution of appropriate permissions) that the publication editor isthe only party that may grant permissions to write into the container,and that the organization librarian is the only party that may indexand/or abstract the content. In addition, the publisher 3308 may, forexample, allow only certain one or more parties to finalize a containerfor delivery to the repository 3302 in usable form (e.g. by maintainingcontrol over the type of permissions, including distributionpermissions, that may be required by the repository 3302 to performsubsequent distribution activities related to repository end users3310).

[2439] In this example, author 3306E is connected directly to thepublisher 3308, such that the publisher 3308 can provide templates forthat author that establish the character of containers for author3306E's content. For example, if author 3306E creates books fordistribution by the publisher 3308, the publisher 3308 may define theVDE control structure template which provides control method options forauthor 3306E to select from and which provides VDE control structuresfor securely distributing author 3306E's works. Author 3306E and thepublisher 3308 may employ VDE negotiations for the templatecharacteristics, specific control structures, and/or parameter data usedby author 3306E. Author 3306E may then use the template(s) to createcontrol structures for their content containers. The publisher 3308 maythen deliver these works to the repository 3302 under a VDE extendedagreement comprising electronic agreements between author 3306E and thepublisher 3308 and the repository 3302 and the publisher 3308.

[2440] In this example, the publisher 3308 may also make author 3306E'swork available on the local repository 3302. The editor may authorize(e.g. through distribution of appropriate permissions) author F tocreate certain portions of content for a publication. In this example,the editor may review and/or modify author F's work and further includeit in a container with content provided by author 3306E (available onthe local repository 3302). The editor may or may not have permissionsfrom the publisher 3308 to modify author 3306E's content (depending onany negotiation(s) that may have occurred between the publisher 3308 andauthor 3306E, and the publisher 3308's decision to extend such rights tothe editor if permissions to modify author 3306E's content are held inredistributable form by the publisher 3308). The editor may also includecontent from other authors by (a) using a process of grantingpermissions to authors to write directly into the containers and/or (b)retrieving containers from the local repository 3302 for inclusion. Thelocal repository 3302 may also be used for other material used by thepublisher 3308's organization (e.g. databases, other reference works,internal documents, draft works for review, training videos, etc.), suchmaterial may, given appropriate permissions, be employed in VDEcontainer collections of content created by the editor.

[2441] The librarian in this example has responsibility for buildingand/or editing inverted indexes, keyword lists (e.g. from a restrictedvocabulary), abstracts of content, revision histories, etc. Thepublisher 3308 may, for example, grant permissions to only the librarianfor creating this type of content. The publisher 3308 may furtherrequire that this building and/or editing occur prior to release ofcontent to the repository 3302.

[2442] Example—Evolution and Transformation of VDE Managed Content andControl Information

[2443] The VDE content control architecture allows content controlinformation (such as control information for governing content usage) tobe shaped to conform to VDE control information requirements of multipleparties. Formulating such multiple party content control informationnormally involves securely deriving control information from controlinformation securely contributed by parties who play a role in a contenthandling and control model (e.g. content creator(s), provider(s),user(s), clearinghouse(s), etc.). Multiple party control information maybe necessary in order to combine multiple pieces of independentlymanaged VDE content into a single VDE container object (particularly ifsuch independently managed content pieces have differing, for exampleconflicting, content control information). Such secure combination ofVDE managed pieces of content will frequently require VDE's ability tosecurely derive content control information which accommodates thecontrol information requirements, including any combinatorial rules, ofthe respective VDE managed pieces of content and reflects an acceptableagreement between such plural control information sets.

[2444] The combination of VDE managed content pieces may result in a VDEmanaged composite of content. Combining VDE managed content must becarried out in accordance with relevant content control informationassociated with said content pieces and processed through the use of oneor more secure VDE sub-system PPEs 650. VDE's ability to support theembedding, or otherwise combining, of VDE managed content pieces, so asto create a combination product comprised of various pieces of VDEcontent, enables VDE content providers to optimize their VDE electroniccontent products. The combining of VDE managed content pieces may resultin a VDE content container which “holds” consolidated content and/orconcomitant, separate, nested VDE content containers.

[2445] VDE's support for creation of content containers holding distinctpieces of VDE content portions that were previously managed separatelyallows VDE content providers to develop products whose content controlinformation reflects value propositions consistent with the objectivesof the providers of content pieces, and further are consistent with theobjectives of a content aggregator who may be producing a certaincontent combination as a product for commercial distribution. Forexample, a content product “launched” by a certain content provider intoa commercial channel (such as a network repository) may be incorporatedby different content providers and/or end-users into VDE contentcontainers (so long as such incorporation is allowed by the launchedproduct's content control information). These different contentproviders and/or end-users may, for example, submit differing controlinformation for regulating use of such content. They may also combine indifferent combinations a certain portion of launched content withcontent received from other parties (and/or produced by themselves) toproduce different content collections, given appropriate authorizations.

[2446] VDE thus enables copies of a given piece of VDE managed contentto be securely combined into differing consolidations of content, eachof which reflects a product strategy of a different VDE contentaggregator. VDE's content aggregation capability will result in a widerrange of competitive electronic content products which offer differingoverall collections of content and may employ differing content controlinformation for content that may be common to such multiple products.Importantly, VDE securely and flexibly supports editing the content in,extracting content from, embedding content into, and otherwise shapingthe content composition of, VDE content containers. Such capabilitiesallow VDE supported product models to evolve by progressively reflectingthe requirements of “next” participants in an electronic commercialmodel. As a result, a given piece of VDE managed content, as it movesthrough pathways of handling and branching, can participate in manydifferent content container and content control information commercialmodels.

[2447] VDE content, and the electronic agreements associated with saidcontent, can be employed and progressively manipulated in commercialways which reflect traditional business practices for non-electronicproducts (though VDE supports greater flexibility and efficiencycompared with most of such traditional models). Limited only by the VDEcontrol information employed by content creators, other providers, andother pathway of handling and control participants, VDE allows a“natural” and unhindered flow of, and creation of, electronic contentproduct models. VDE provides for this flow of VDE products and servicesthrough a network of creators, providers, and users who successively andsecurely shape and reshape product composition through contentcombining, extracting, and editing within a Virtual DistributionEnvironment.

[2448] VDE provides means to securely combine content provided atdifferent times, by differing sources, and/or representing differingcontent types. These types, timings, and/or different sources of contentcan be employed to form a complex array of content within a VDE contentcontainer. For example, a VDE content container may contain a pluralityof different content container objects, each containing differentcontent whose usage can be controlled, at least in part, by its owncontainer's set of VDE content control information.

[2449] A VDE content container object may, through the use of a secureVDE sub-system, be “safely” embedded within a “parent” VDE contentcontainer. This embedding process may involve the creation of anembedded object, or, alternatively, the containing, within a VDE contentcontainer, of a previously independent and now embedded object by, atminimum, appropriately referencing said object as to its location.

[2450] An embedded content object within a parent VDE content container:

[2451] (1) may have been a previously created VDE content containerwhich has been embedded into a parent VDE content container by securelytransforming it from an independent to an embedded object through thesecure processing of one or more VDE component assemblies within a VDEsecure sub-system PPE 650. In this instance, an embedded object may besubject to content control information, including one or morepermissions records associated with the parent container, but may not,for example, have its own content control information other than contentidentification information, or the embedded object may be moreextensively controlled by its own content control information (e.g.permissions records).

[2452] (2) may include content which was extracted from another VDEcontent container (along with content control information, as may beapplicable) for inclusion into a parent VDE content container in theform of an embedded VDE content container object. In this case, saidextraction and embedding may use one or more VDE processes which runsecurely within a VDE secure sub-system PPE 650 and which may securelyremove (or copy) the desired content from a source VDE content containerand place such content in a new or existing container object, either ofwhich may be or become embedded into a parent VDE content container.

[2453] (3) may include content which was first created and then placedin a VDE content container object. Said receiving container may alreadybe embedded in a parent VDE content container and may already containother content. The container in which such content is placed may bespecified using a VDE aware application which interacts with content anda secure VDE subsystem to securely create such VDE container and placesuch content therein followed by securely embedding such container intothe destination, parent container. Alternatively, content may bespecified without the use of a VDE aware application, and thenmanipulated using a VDE aware application in order to manage movement ofthe content into a VDE content container. Such an application may be aVDE aware word processor, desktop and/or multimedia publishing package,graphics and/or presentation package, etc. It may also be an operatingsystem function (e.g. part of a VDE aware operating system ormini-application operating with an O/S such as a Microsoft Windowscompatible object packaging application) and movement of content from“outside” VDE to within a VDE object may, for example, be based on a“drag and drop” metaphor that involves “dragging” a file to a VDEcontainer object using a pointing device such as a mouse. Alternatively,a user may “cut” a portion of content and “paste” such a portion into aVDE container by first placing content into a “clipboard,” thenselecting a target content object and pasting the content into such anobject. Such processes may, at the direction of VDE content controlinformation and under the control of a VDE secure subsystem, put thecontent automatically at some position in the target object, such as atthe end of the object or in a portion of the object that corresponds toan identifier carried by or with the content such as a field identifier,or the embedding process might pop-up a user interface that allows auser to browse a target object's contents and/or table of contentsand/or other directories, indexes, etc. Such processes may further allowa user to make certain decisions concerning VDE content controlinformation (budgets limiting use, reporting pathway(s), usageregistration requirements, etc.) to be applied to such embedded contentand/or may involve selecting the specific location for embedding thecontent, all such processes to be performed as transparently aspractical for the application.

[2454] (4) may be accessed in conjunction with one or more operatingsystem utilities for object embedding and linking, such as utilitiesconforming to the Microsoft OLE standard. In this case, a VDE containermay be associated with an OLE “link.” Accesses (including readingcontent from, and writing content to) to a VDE protected container maybe passed from an OLE aware application to a VDE aware OLE applicationthat accesses protected content in conjunction with control informationassociated with such content.

[2455] A VDE aware application may also interact with componentassemblies within a PPE to allow direct editing of the content of a VDEcontainer, whether the content is in a parent or embedded VDE contentcontainer. This may include the use of a VDE aware word processor, forexample, to directly edit (add to, delete, or otherwise modify) a VDEcontainer's content. The secure VDE processes underlying VDE containercontent editing may be largely or entirely transparent to the editor(user) and may transparently enable the editor to securely browsethrough (using a VDE aware application) some or all of the contents of,and securely modify one or more of the VDE content containers embeddedin, a VDE content container hierarchy.

[2456] The embedding processes for all VDE embedded content containersnormally involves securely identifying the appropriate content controlinformation for the embedded content. For example, VDE content controlinformation for a VDE installation and/or a VDE content container maysecurely, and transparently to an embedder (user), apply the samecontent control information to edited (such as modified or additional)container content as is applied to one or more portions (including all,for example) of previously “in place” content of said container and/orsecurely apply control information generated through a VDE controlinformation negotiation between control sets, and/or it may applycontrol information previously applied to said content. Application ofcontrol information may occur regardless of whether the edited contentis in a parent or embedded container. This same capability of securelyapplying content control information (which may be automatically and/ortransparently applied), may also be employed with content that isembedded into a VDE container through extracting and embedding content,or through the moving, or copying and embedding, of VDE containerobjects. Application of content control information normally occurssecurely within one or more VDE secure sub-system PPEs 650. This processmay employ a VDE template that enables a user, through easy to use GUIuser interface tools, to specify VDE content control information forcertain or all embedded content, and which may include menu driven, userselectable and/or definable options, such as picking amongst alternativecontrol methods (e.g. between different forms of metering) which may berepresented by different icons picturing (symbolizing) different controlfunctions and apply such functions to an increment of VDE securedcontent, such as an embedded object listed on an object directorydisplay.

[2457] Extracting content from a VDE content container, or editing orotherwise creating VDE content with a VDE aware application, providescontent which may be placed within a new VDE content container objectfor embedding into said parent VDE container, or such content may bedirectly placed into a previously existing content container. All ofthese processes may be managed by processing VDE content controlinformation within one or more VDE installation secure sub-systems.

[2458] VDE content container objects may be embedded in a parent objectthrough control information referenced by a parent object permissionsrecord that resolves said embedded object's location and/or contents. Inthis case, little or no change to the embedded object's previouslyexisting content control information may be required. VDE securelymanaged content which is relocated to a certain VDE content containermay be relocated through the use of VDE sub-system secure processeswhich may, for example, continue to maintain relocated content asencrypted or otherwise protected (e.g. by secure tamper resistantbarrier 502) during a relocation/embedding process.

[2459] Embedded content (and/or content objects) may have beencontributed by different parties and may be integrated into a VDEcontainer through a VDE content and content control informationintegration process securely managed through the use of one or moresecure VDE subsystems. This process may, for example, involve one ormore of:

[2460] (1.) securely applying instructions controlling the embeddingand/or use of said submitted content, wherein said instructions weresecurely put in place, at least in part, by a content provider and/oruser of said VDE container. For example, said user and/or provider mayinteract with one or more user interfaces offering a selection ofcontent embedding and/or control options (e.g. in the form of a VDEtemplate). Such options may include which, and/or whether, one or morecontrols should be applied to one or more portions of said contentand/or the entry of content control parameter data (such a time periodbefore which said content may not be used, cost of use of content,and/or pricing discount control parameters such as software programsuite sale discounting). Once required and/or optional content controlinformation is established by a provider and/or user, it may function ascontent control information which may be, in part or in full, appliedautomatically to certain, or all, content which is embedded in a VDEcontent container.

[2461] (2.) secure VDE managed negotiation activities, including the useof a user interface interaction between a user at a receiving VDEinstallation and VDE content control information associated with thecontent being submitted for embedding. For example, such associatedcontrol information may propose certain content information and thecontent receiver may, for example, accept, select from a plurality,reject, offer alternative control information, and/or apply conditionsto the use of certain content control information (for example, accept acertain one or more controls if said content is used by a certain one ormore users and/or if the volume of usage of certain content exceeds acertain level).

[2462] (3.) a secure, automated, VDE electronic negotiation processinvolving VDE content control information of the receiving VDE contentcontainer and/or VDE installation and content control informationassociated with the submitted content (such as control information in apermissions record of a contributed VDE object, certain componentassemblies, parameter data in one or more UDEs and/or MDEs, etc.).

[2463] Content embedded into a VDE content container may be embedded inthe form of:

[2464] (1.) content that is directly, securely integrated intopreviously existing content of a VDE content container (said containermay be a parent or embedded content container) without the formation ofa new container object. Content control information associated with saidcontent after embedding must be consistent with any pre-embeddingcontent control information controlling, at least in part, theestablishment of control information required after embedding. Contentcontrol information for such directly integrated, embedded content maybe integrated into, and/or otherwise comprise a portion of, controlinformation (e.g. in one or more permissions records containing contentcontrol information) for said VDE container, and/or

[2465] (2.) content that is integrated into said container in one ormore objects which are nested within said VDE content container object.In this instance, control information for said content may be carried byeither the content control information for the parent VDE contentcontainer, or it may, for example, be in part or in full carried by oneor more permissions records contained within and/or specificallyassociated with one or more content containing nested VDE objects. Suchnesting of VDE content containing objects within a parent VDE contentcontainer may employ a number of levels, that is a VDE content containernested in a VDE content container may itself contain one or more nestedVDE content containers.

[2466] VDE content containers may have a nested structure comprising oneor more nested containers (objects) that may themselves store furthercontainers and/or one or more types of content, for example, text,images, audio, and/or any other type of electronic information (objectcontent may be specified by content control information referencing, forexample, byte offset locations on storage media). Such content may bestored, communicated, and/or used in stream (such as dynamicallyaccumulating and/or flowing) and/or static (fixed, such as predefined,complete file) form. Such content may be derived by extracting a subsetof the content of one or more VDE content containers to directly produceone or more resulting VDE content containers. VDE securely managedcontent (e.g. through the use of a VDE aware application or operatingsystem having extraction capability) may be identified for extractionfrom each of one or more locations within one or more VDE contentcontainers and may then be securely embedded into a new or existing VDEcontent container through processes executing VDE controls in a securesubsystem PPE 650. Such extraction and embedding (VDE “exporting”)involves securely protecting, including securely executing, the VDEexporting processes.

[2467] A VDE activity related to VDE exporting and embedding involvesperforming one or more transformations of VDE content from one secureform to one or more other secure forms. Such transformation(s) may beperformed with or without moving transformed content to a new VDEcontent container (e.g. by component assemblies operating within a PPEthat do not reveal, in unprotected form, the results or other output ofsuch transforming processes without further VDE processes governing useof at least a portion of said content). One example of such atransformation process may involve performing mathematicaltransformations and producing results, such as mathematical results,while retaining, none, some, or all of the content information on whichsaid transformation was performed. Other examples of suchtransformations include converting a document format (such as from aWordPerfect format to a Word for Windows format, or an SGML document toa Postscript document), changing a video format (such as a QuickTimevideo format to a MPEG video format), performing an artificialintelligence process (such as analyzing text to produce a summaryreport), and other processing that derives VDE secured content fromother VDE secured content.

[2468]FIG. 79 shows an example of an arrangement of commercial VDEusers. The users in this example create, distribute, redistribute, anduse content in a variety of ways. This example shows how certain aspectsof control information associated with content may evolve as controlinformation passes through a chain of handling and control. These VDEusers and controls are explained in more detail below.

[2469] Creator A in this example creates a VDE container and providesassociated content control information that includes references (amongstother things to several examples of possible “types” of VDE controlinformation. In order to help illustrate this example, some of the VDEcontrol information passed to another VDE participant is grouped intothree categories in the following more detailed discussion: distributioncontrol information, redistribution control information, and usagecontrol information. In this example, a fourth category of embeddingcontrol information can be considered an element of all three of thepreceding categories. Other groupings of control information arepossible (VDE does not require organizing control information in thisway). The content control information associated with this example of acontainer created by creator A is indicated on FIG. 80 as C_(A). FIG. 80further shows the VDE participants who may receive enabling controlinformation related to creator A's VDE content container. Some of thecontrol information in this example is explained in more detail below.

[2470] Some of the distribution control information (in this example,control information primarily associated with creation, modification,and/or use of control information by distributors) specified by creatorA includes: (a) distributors will compensate creator A for each activeuser of the content of the container at the rate of $10 per user permonth, (b) distributors are budgeted such that they may allow no morethan 100 independent users to gain access to such content (i.e. maycreate no more than 100 permissions records reflecting content accessrights) without replenishing this budget, and (c) no distribution rightsmay be passed on in enabling control information (e.g. permissionsrecords and associated component assemblies) created for distribution toother participants.

[2471] Some of the content redistribution control information (in thisexample, control information produced by a distributor within the scopepermitted by a more senior participant in a chain of handling andcontrol and passed to user/providers (in this example,user/distributors) and associated with controls and/or otherrequirements associated with redistribution activities by suchuser/distributors) specified by creator A includes: (a) a requirementthat control information enabling content access may be redistributed byuser/distributors no more than 2 levels, and further requires that eachredistribution decrease this value by one, such that a firstredistributor is restricted to two levels of redistribution, and asecond redistributor to whom the first redistributor deliverspermissions will be restricted to one additional level ofredistribution, and users receiving permissions from the secondredistributor will be unable to perform further redistribution (such arestriction may be enforced, for example, by including as one aspect ofa VDE control method associated with creating new permissions arequirement to invoke one or more methods that: (i) locate the currentlevel of redistribution stored, for example, as an integer value in aUDE associated with such one or more methods, (ii) compare the level ofredistribution value to a limiting value, and (iii) if such level ofredistribution value is less than the limiting value, increment suchlevel of redistribution value by one before delivering such a UDE to auser as an aspect of content control information associated with VDEmanaged content, or fail the process if such value is equal to such alimiting value), and (b) no other special restrictions are placed onredistributors.

[2472] Some of the usage control information (in this example, controlinformation that a creator requires a distributor to provide in controlinformation passed to users and/or user/distributors) specified bycreator A may include, for example: (a) no moves (a form of distributionexplained elsewhere in this document) of the content are permitted, and(b) distributors will be required to preserve (at a minimum) sufficientmetering information within usage permissions in odder to calculate thenumber of users who have accessed the container in a month and toprevent further usage after a rental has expired (e.g. by using a metermethod designed to report access usages to creator A through a chain ofhandling and reporting, and/or the use of expiration dates and/ortime-aged encryption keys within a permissions record or other requiredcontrol information).

[2473] Some of the extracting and/or embedding control informationspecified by creator A in this example may include a requirement that noextracting and/or embedding of the content is or will be permitted byparties in a chain of handling and control associated with this controlinformation, except for users who have no redistribution rights relatedto such VDE secured content provided by Creator A. Alternatively, or inaddition, as regards different portions of said content, controlinformation enabling certain extraction and/or embedding may be providedalong with the redistribution rights described in this example for useby user/distributors (who may include user content aggregators, that isthey may provide content created by, and/or received from, differentsources so as to create their own content products).

[2474] Distributor A in this example has selected a basic approach thatdistributor A prefers when offering enabling content control informationto users and/or user/distributors that favors rental of content accessrights over other approaches. In this example, some of the controlinformation provided by creators will permit distributor A to fulfillthis favored approach directly, and other control structures maydisallow this favored approach (unless, for example, distributor Acompletes a successful VDE negotiation allowing such an approach andsupporting appropriate control information). Many of the controlstructures received by distributor A, in this example, are derived from(and reflect the results of) a VDE negotiation process in whichdistributor A indicates a preference for distribution controlinformation that authorizes the creation of usage control informationreflecting rental based usage rights. Such distribution controlinformation may allow distributor A to introduce and/or modify controlstructures provided by creators in such a way as to create controlinformation for distribution to users and/or user/distributors that, ineffect, “rent” access rights. Furthermore, distributor A in this exampleservices requests from user/distributors for redistribution rights, andtherefore also favors distribution control information negotiated (orotherwise agreed to) with creators that permits distributor A to includesuch rights as an aspect of control information produced by distributorA.

[2475] In this example, distributor A and creator A may use VDE tonegotiate (for example, VDE negotiate) for a distribution relationship.Since in this example creator A has produced a VDE content container andassociated control information that indicates creator A's desire toreceive compensation based on rental of usage rights, and such controlinformation further indicates that creator A has placed acceptablerestrictions in redistribution control information that distributor Amay use to service requests from user/distributors, distributor A mayaccept creator A's distribution control information without anynegotiated changes.

[2476] After receiving enabling distribution control information fromcreator A, distributor A may manipulate an application program tospecify some or all of the particulars of usage control information forusers and/or user/distributors enabled by distributor A (as allowed, ornot prevented, by senior control information). Distributor A may, forexample, determine that a price of $15 per month per user would meetdistributor A's business objectives with respect to payments from usersfor creator A's container. Distributor A must specify usage controlinformation that fulfill the requirements of the distribution controlinformation given to distributor A by creator A. For example,distributor A may include any required expiration dates and/or time-agedencryption keys in the specification of control information inaccordance with creator A's requirements. If distributor A failed toinclude such information (or to meet other requirements) in theirspecification of control information, the control method(s) referencedin creator A's permissions record and securely invoked within a PPE 650to actually create this control information would, in this example, failto execute in the desired way (e.g. based on checks of proposed valuesin certain fields, a requirement that certain methods be included inpermissions, etc.) until acceptable information were included indistributor A's control information specification.

[2477] In this example, user A may have established an account withdistributor A such that user A may receive VDE managed content usagecontrol information from distributor. A User A may receive content usagecontrol information from distributor A to access and use creator A'scontent. Since the usage control information has passed through (andbeen added to, and/or modified by) a chain of handling includingdistributor A, the usage control information requested from distributorA to make use of creator A's content will, in this example, reflect acomposite of control information from creator A and distributor A. Forexample, creator A may have established a meter method that willgenerate an audit record if a user accesses creator A's VDE controlledcontent container if the user has not previously accessed the containerwithin the same calendar month (e.g. by storing the date of the user'slast access in a UDE associated with an open container event referencedin a method core of such a meter method and comparing such a date uponsubsequent access to determine if such access has occurred within thesame calendar month). Distributor A may make use of such a meter methodin a control method (e.g. also created and/or provided by creator A, orcreated and/or provided by distributor A) associated with openingcreator A's container that invokes one or more billing and/or budgetmethods created, modified, referenced in one or more permissions recordsand/or parameterized by distributor A to reflect a charge for monthlyusage as described above. If distributor A has specified usage and/orredistribution control information within the boundaries permitted bycreator A's senior control information, a new set of control information(shown as D_(A)(C_(A)) in FIG. 80) may be associated with creator A'sVDE content container when control information associated with thatcontainer by distributor A are delivered to users and/oruser/distributors (user A, user B, and user/distributor A in thisexample).

[2478] In this example, user A may receive control information relatedto creator A's VDE content container from distributor A. This controlinformation may represent an extended agreement between user A anddistributor A (e.g. regarding fees associated with use of content,limited redistribution rights, etc.) and distributor A and creator A(e.g. regarding the character, extent, handling, reporting, and/or otheraspects of the use and/or creation of VDE controlled content usageinformation and/or content control information received, for example, bydistributor A from creator A, or vice versa, or in other VDE contentusage information handling). Such an extended agreement is enforced byprocesses operating within a secure subsystem of each participant's VDEinstallation. The portion of such an extended agreement representingcontrol information of creator A as modified by distributor A in thisexample is represented by D_(A)(C_(A)), including, for example, (a)control structures (e.g. one or more component assemblies, one or morepermissions records, etc.), (b) the recording of usage informationgenerated in the course of using creator A's content in conformance withrequirements stated in such control information, (c) making payments(including automatic electronic credit and/or currency payments“executed” in response to such usage) as a consequence of such usage(wherein such consequences may also include electronically, securely andautomatically receiving a bill delivered through use of VDE, whereinsuch a bill is derived from said usage), (d) other actions by user Aand/or a VDE secure subsystem at user A's VDE installation that are aconsequence of such usage and/or such control information.

[2479] In addition to control information D_(A)(C_(A)), user A mayenforce her own control information on her usage of creator A's VDEcontent container (within the limits of senior content controlinformation). This control information may include, for example, (a)transaction, session, time based, and/or other thresholds placed onusage such that if such thresholds (e.g. quantity limits, for example,self imposed limits on the amount of expenditure per activity parameter)are exceeded user A must give explicit approval before continuing, (b)privacy requirements of user A with respect to the recording and/ortransmission of certain usage related details relating to user A's usageof creator A's content, (c) backup requirements that user A places onherself in order to help ensure a preservation of value remaining increator A's content container and/or local store of electronic creditand/or currency that might otherwise be lost due to system failure orother causes. The right to perform in some or all of these examples ofuser A's control information, in some examples, may be negotiated withdistributor A. Other such user specified control information may beenforced independent of any control information received from anycontent provider and may be set in relationship to a user's, or moregenerally, a VDE installation's, control information for one or moreclasses, or for all classes, of content and/or electronic applianceusage. The entire set of VDE control information that may be in placeduring user A's usage of creator A's content container is referred to onFIG. 80 as U_(A)(D_(A)(C_(A))). This set may represent the controlinformation originated by creator A, as modified by distributor A, asfurther modified by user A, all in accordance with control informationfrom value chain parties providing more senior control information, andtherefore constitutes, for this example, a “complete” VDE extendedagreement between user A, distributor A, and creator A regarding creatorA's VDE content container. User B may, for example, also receive suchcontrol information D_(A)(C_(A)) from distributor A, and add her owncontrol information in authorized ways to form the setU_(B)(D_(A)(C_(A))).

[2480] User/distributor A may also receive VDE control information fromdistributor A related to creator A's VDE content container.User/distributor A may, for example, both use creator A's content as auser and act as a redistributor of control information. In this example,control information D_(A)(C_(A)) both enables and limits these twoactivities. To the extent permitted by D_(A)(C_(A)) user/distributor Amay create their own control information based onD_(A)(C_(A))—UD_(A)(D_(A)(C_(A)))—that controls both user/distributorA's usage (in a manner similar to that described above in connectionwith user A and user B), and control information redistributed byuser/distributor A (in a manner similar to that described above inconnection with distributor A). For example, if user/distributor Aredistributes UD_(A)(D_(A)(C_(A))) to user/distributor B,user/distributor B may be required to report certain usage informationto user/distributor A that was not required by either creator A ordistributor A. Alternatively or in addition, user/distributor B may, forexample, agree to pay user/distributor A a fee to use creator A'scontent based on the number of minutes user/distributor B uses creatorA's content (rather than the monthly fee charged to user/distributor Aby distributor A for user/distributor B's usage).

[2481] In this example, user/distributor A may distribute controlinformation UD_(A)(D_(A)(C_(A))) to user/distributor B that permitsuser/distributor B to further redistribute control informationassociated with creator A's content. User/distributor B may make a newset of control information UD_(B)(UD_(A)(D_(A)(C_(A)))). If the controlinformation UD_(A)(D_(A)(C_(A))) permits user/distributor B toredistribute, the restrictions on redistribution from creator A in thisexample will prohibit the set UD_(B)(UD_(A)(D_(A)(C_(A)))) fromincluding further redistribution rights (e.g. providing redistributionrights to user B) because the chain of handling from distributor A touser/distributor A (distribution) and the continuation of that chainfrom user/distributor A to user/distributor B (first level ofredistribution) and the further continuation of that chain to anotheruser represents two levels of redistribution, and, therefore, a setUD_(B)(UD_(A)(D_(A)(C_(A)))) may not, in this example, include furtherredistribution rights.

[2482] As indicated in FIG. 79, user B may employ content from bothuser/distributor B and distributor A (amongst others). In this example,as illustrated in FIG. 80, user B may receive control informationassociated with creator A's content from distributor A and/oruser/distributor B. In either case, user B may be able to establishtheir own control information on D_(A)(C_(A)) and/orUD_(B)(UD_(A)(D_(A)(C_(A)))), respectively (if allowed by such controlinformation. The resulting set(s) of control information,U_(B)(D_(A)(C_(A))) and/or U_(B)(UD_(B)(UD_(A)(D_(A)(C_(A)))))respectively, may represent different control scenarios, each of whichmay have benefits for user B. As described in connection with an earlierexample, user B may have received control information fromuser/distributor B along a chain of handling including user/distributorA that bases fees on the number of minutes that user B makes use ofcreator A's content (and requiring user/distributor A to pay fees of $15per month per user to distributor A regardless of the amount of usage byuser B in a calendar month). This may be more favorable under somecircumstances than the fees required by a direct use of controlinformation provided by distributor A, but may also have thedisadvantage of an exhausted chain of redistribution and, for example,further usage information reporting requirements included inUD_(B)(UD_(A)(D_(A)(C_(A)))). If the two sets of control informationD_(A)(C_(A)) and UD_(B)(UD_(A)(D_(A)(C_(A)))) permit (e.g. do notrequire exclusivity enforced, for example, by using a registrationinterval in an object registry used by a secure subsystem of user B'sVDE installation to prevent deregistration and reregistration ofdifferent sets of control information related to a certain container (orregistration of plural copies of the same content having differentcontrol information and/or being supplied by different contentproviders) within a particular interval of time as an aspect of anextended agreement for a chain of handling and control reflected inD_(A)(C_(A)) and/or UD_(B)(UD_(A)(D_(A)(C_(A))))), user B may have bothsets of control information registered and may make use of the set thatthey find preferable under a given usage scenario.

[2483] In this example, creator B creates a VDE content container andassociates a set of VDE control information with such containerindicated in FIG. 81 as C_(B). FIG. 81 further shows the VDEparticipants who may receive enabling control information related tocreator B's VDE content container. In this example, control informationmay indicate that distributors of creator B's content: (a) must paycreator B $0.50 per kilobyte of information decrypted by users and/oruser/distributors authorized by such a distributor, (b) may allow usersand/or user/distributors to embed their content container in anothercontainer while maintaining a requirement that creator B receive $0.50per kilobyte of content decrypted, (c) have no restrictions on thenumber of enabling control information sets that may be generated forusers and/or user/distributors, (d) must report information concerningthe number of such distributed control information sets at certain timeintervals (e.g. at least once per month), (e) may create controlinformation that allows users and/or user/distributors to perform up tothree moves of their control information, (f) may allow redistributionof control information by user/distributors up to three levels ofredistribution, (g) may allow up to one move per user receivingredistributed control information from a user/distributor.

[2484] In this example, distributor A may request control informationfrom creator B that enables distributor A to distribute controlinformation to users and/or user/distributors that is associated withthe VDE container described above in connection with creator B. Asstated earlier, distributor A has established a business model thatfavors “rental” of access rights to users and user/distributorsreceiving such rights from distributor A. Creator B's distributioncontrol information in this example does not force a model including“rental” of rights, but rather bases payment amounts on the quantity ofcontent decrypted by a user or user/distributor. In this example,distributor A may use VDE to negotiate with creator B to include adifferent usage information recording model allowed by creator B. Thismodel may be based on including one or more meter methods in controlstructures associated with creator B's container that will record thenumber of bytes decrypted by end users, but not charge users a fee basedon such decryptions; rather distributor A proposes, and creator B'scontrol information agrees to allow, a “rental” model to charge users,and determines the amount of payments to creator B based on informationrecorded by the bytes decrypted meter methods and/or collections ofpayment from users.

[2485] Creator B may, for example, (a) accept such a new control modelwith distributor A acting as the auditor (e.g. trusting a control methodassociated with processing audit information received by distributor Afrom users of creator B's content using a VDE secure subsystem atdistributor A's site, and further to securely calculate amounts owed bydistributor A to creator B and, for example, making payments to creatorB using a mutually acceptable budget method managing payments to creatorB from credit and/or currency held by distributor A), (b) accept such anew control model based on distributor A's acceptance of a third partyto perform all audit functions associated with this content, (c) mayaccept such a model if information associated with the one or more metermethods that record the number of bytes decrypted by users is securelypackaged by distributor B's VDE secure subsystem and is securely,employing VDE communications techniques, sent to creator B in additionto distributor A, and/or (d) other mutually acceptable conditions.Control information produced by distributor A based on modificationsperformed by distributor A as permitted by C_(B) are referred to in thisexample as D_(A)(C_(B)).

[2486] User A may receive a set of control information D_(A)(C_(B)) fromdistributor A. As indicated above in connection with content receivedfrom creator A via a chain of handling including distributor A, user Amay apply their own control information to the control informationD_(A)(C_(B)), to the extent permitted by D_(A)(C_(B)), to produce a setof control information U_(A)(D_(A)(C_(B))). The set of controlinformation D_(A)(C_(B)) may include one or more meter methods thatrecord the number of bytes of content from creator B's containerdecrypted by user A (in order to allow correct calculation of amountsowed by distributor A to creator B for user A's usage of creator B'scontent in accordance with the control information of C_(B) thatrequires payment of $0.50 per kilobyte of decrypted information), and afurther meter method associated with recording usage such thatdistributor A may gather sufficient information to securely generatebillings associated with user A's usage of creator B's content and basedon a “rental” model (e.g. distributor A may, for example, have includeda meter method that records each calendar month that user A makes use ofcreator B's content, and relates to further control information thatcharges user A $10 per month for each such month during which user Amakes use of such content.)

[2487] User/distributor A may receive control information C_(B) directlyfrom creator B. In this case, creator B may use VDE to negotiate withuser/distributor A and deliver a set of control information C_(B) thatmay be the same or differ from that described above in connection withthe distribution relationship established between creator B anddistributor A. For example, user/distributor A may receive controlinformation C_(B) that includes a requirement that user/distributor Apay creator B for content decrypted by user/distributor A (and anyparticipant receiving distributed and/or redistributed controlinformation from user/distributor A) at the rate of $0.50 per kilobyte.As indicated above, user/distributor A also may receive controlinformation associated with creator B's VDE content container fromdistributor A. In this example, user/distributor A may have a choicebetween paying a “rental” fee through a chain of handling passingthrough distributor A, and a fee based on the quantity of decryptionthrough a chain of handling direct to creator B. In this case,user/distributor A may have the ability to choose to use either or bothof C_(B) and D_(A)(C_(B)). As indicated earlier in connection with achain of handling including creator A and distributor A,user/distributor A may apply her own control information to the extentpermitted by C_(B) and/or D_(A)(C_(B)) to form the sets of controlinformation UD_(A)(C_(B)) and UD_(A)(D_(A)(C_(B))), respectively.

[2488] As illustrated in FIG. 81, in this example, user B may receivecontrol information associated with creator B's VDE content containerfrom six different sources: C_(B) directly from creator B, D_(A)(C_(B))from distributor A, UD_(B)(UD_(A)(D_(A)(C_(B)))) and/orUD_(B)(UD_(A)(C_(B))) from user/distributor B, D_(C)(C_(B)) fromdistributor C, and/or D_(B)(D_(C)(C_(B))) from distributor B. Thisrepresents six chains of handling through which user B may enter intoextended agreements with other participants in this example. Two ofthese chains pass through user/distributor B. Based on a VDE negotiationbetween user/distributor B and user B, an extended agreement may bereached (if permitted by control information governing both parties)that reflects the conditions under which user B may use one or both setsof control information. In this example, two chains of handling andcontrol may “converge” at user/distributor B, and then pass to user B(and if control information permits, later diverge once again based ondistribution and/or redistribution by user B).

[2489] In this example, creator C produces one or more sets of controlinformation C_(C) associated with a VDE content container created bycreator C, as shown in FIG. 82. FIG. 82 further shows the VDEparticipants who may receive enabling control information related tocreator C's VDE content container. The content in such a container is,in this example, organized into a set of text articles. In this examplecontrol information may include one or more component assemblies thatdescribe the articles within such a container (e.g. one or more eventmethods referencing map tables and/or algorithms that describe theextent of each article). C_(c) may further include, for example: (a) arequirement that distributors ensure that creator C receive $1 perarticle accessed by users and/or user/distributors, which payment allowsa user to access such an article for a period of no more than six months(e.g. using a map-type meter method that is aged once per month, timeaged decryption keys, expiration dates associated with relevantpermissions records, etc.), (b) control information that allows articlesfrom creator C's container to be extracted and embedded into anothercontainer for a one time charge per extract/embed of $10, (c) prohibitsextracted/embedded articles from being reextracted, (d) permitsdistributors to create enabling control information for up to 1000 usersor user/distributors per month, (e) requires that information regardingthe number of users and user/distributors enabled by a distributor bereported to creator C at least once per week, (f) permits distributorsto enable users or user/distributors to perform up to one move ofenabling control information, and (g) permits up to 2 levels ofredistribution by user/distributors.

[2490] In this example, distributor B may establish a distributionrelationship with creator C. Distributor B in this example may haveestablished a business model that favors the distribution of controlinformation to users and user/distributors that bases payments todistributor B based on the number of accesses performed by such VDEparticipants. In this example, distributor B may create a modified setD_(B)(C_(C)) of enabling control information for distribution to usersand/or user/distributors. This set D_(B)(C_(C)) may, for example, bebased on a negotiation using VDE to establish a fee of $0.10 per accessper user for users and/or user/distributors who receive controlinformation from distributor B. For example, if one or more map-typemeter methods have been included in C_(C) to ensure that adequateinformation may be gathered from users and/or user/distributors toensure correct payments to creator C by distributor B based on C_(C),such methods may be preserved in the set D_(B)(C_(C)), and one or morefurther meter methods (and any other necessary control structures suchas billing and/or budget methods) may be included to record each accesssuch that the set D_(B)(C_(C)) will also ensure that distributor B willreceive payments based on each access.

[2491] The client administrator in this example may receive a set ofcontent control information D_(B)(C_(C)) that differs, for example, fromcontrol information received by user B from distributor B. For example,the client administrator may use VDE to negotiate with distributor B toestablish a set of control information for content from all creators forwhom distributor B may provide enabling content control information tothe client administrator. For example, the client administrator mayreceive a set of control information D_(B)(C_(C)) that reflects theresults of a VDE negotiation between the client administrator anddistributor B. The client administrator may include a set ofmodifications to D_(B)(C_(C)) and form a new set CA(D_(B)(C_(C))) thatincludes control information that may only be available to users anduser/distributors within the same organization as the clientadministrator (e.g. coworkers, employees, consultants, etc.) In order toenforce such an arrangement, CA(D_(B)(C_(C))) may, for example, includecontrol structures that examine name services information associatedwith a user or user/distributor during registration, establish a newbudget method administered by the client administrator and required foruse of the content, etc.

[2492] A distributor may provide redistribution rights to a clientadministrator which allows said administrator to redistribute rights tocreate permissions records for certain content (redistribute rights touse said content) only within the administrator's organization and to noother parties. Similarly, such administrator may extend such a “limited”right to redistribute to department and/or other administrator withinhis organization such that they may redistribute such rights to usecontent based on one or more restricted lists of individuals and/orclasses and/or other groupings of organization personnel as defined bysaid administrator. This VDE capability to limit redistribution tocertain one or more parties and/or classes and/or other groupings of VDEusers and/or installations can be applied to content by any VDE contentprovider, so long as such a control is allowed by senior controlinformation.

[2493] User D in this example may receive control information fromeither the client administrator and/or user/distributor C.User/distributor C may, for example, distribute control informationUD_(C)(CA(D_(B)(C_(C)))) to user D that includes a departmental budgetmethod managed by user/distributor C to allow user/distributor C tomaintain an additional level of control over the actions of user D. Inthis case, UD_(C)(CA(D_(B)(C_(C)))) may include multiple levels oforganizational controls (e.g. controls originating with the clientadministrator and further controls originating with user/distributor C)in addition to controls resulting from a commercial distributionchannel. In addition or alternatively, the client administrator mayrefuse to distribute certain classes of control information to user Deven if the client administrator has adequate control information (e.g.control information distributed to user/distributor C that allowsredistribution to users such as user D) to help ensure that controlinformation flows through the client administrator's organization inaccordance with policies, procedures, and/or other administrativeprocesses.

[2494] In this example, user E may receive control information from theclient administrator and/or distributor B. For example, user E may havean account with distributor B even though some control information maybe received from the client administrator. In this case, user E may bepermitted to request and receive control information from distributor Bwithout restriction, or the client administrator may have, as a matterof organizational policy, control information in place associated withuser E's electronic appliance that limits the scope of user E'sinteraction with distributor B. In the latter case, the clientadministrator may, for example, have limited user E to registeringcontrol information with the secure subsystem of user E's electronicappliance that is not available from the client administrator, is fromone or more certain classes of distributors and/or creators, and/or hasa cost for usage, such as a certain price point (e.g. $50 per hour ofusage). Alternatively or in addition, the client administrator may, forexample, limit user E to receiving control information from distributorB in which user E receives a more favorable price (or other controlinformation criteria) than the price (or other criteria) available incontrol information from the client administrator.

[2495] In this example, creator D may create a VDE content containerthat is designed primarily for integration with other content (e.g.through use of a VDE extracting/embedding process), for example, contentprovided by creator B and creator C. FIG. 83 shows the VDE participantswho may receive enabling control information related a VDE contentcontainer produced by creator D. Control information associated withcreator D's content (C_(D) in FIG. 83) may include, for example: (a) arequirement that distributors make payment of either $1.50 per open peruser, or $25 per user for an unlimited number of opens, (b) a discountof 20% for any user that has previously paid for an unlimited number ofopens for certain other content created by creator D (e.g. implementedby including one or more billing methods that analyze a secure databaseof a user's VDE installation to determine if any of such certain othercontainers are registered, and further determines the character ofrights held by a user purchasing rights to this container), (c) arequirement that distributors report the number of users anduser/distributors enabled by control information produced in accordancewith C_(D) after such number exceeds 1000, (d) a requirement thatdistributors limit the number of moves by users and/or user/distributorsto no more than one, (e) a requirement that distributors limituser/distributors to no more than four levels of redistribution, and (f)that distributors may create enabling control information that permitsother distributors to create control information as distributors, butmay not pass this capability to such enabled distributors, and furtherrequires that audit information associated with use of controlinformation by such enabled distributors shall pass directly to creatorD without processing by such enabling distributor and that creator Dshall pay such an enabling distributor 10% of any payments received bycreator D from such an enabled distributor.

[2496] In this example, distributor C may receive VDE content containersfrom creator B, creator C, and creator D, and associated sets of controlinformation C_(B), C_(C), and C_(D). Distributor C may use the embeddingcontrol information and other control information to produce a newcontainer with two or more VDE objects received from creator B, creatorC, and creator D. In addition or alternatively, distributor C may createenabling control information for distribution to users and/oruser/distributors (or in the case of C_(D), for distributors) for suchreceived containers individually. For example, distributor C may createa container including content portions (e.g. embedded containers) fromcreator B, creator C, and creator D in which each such portion hascontrol information related to its access and use that records, andallows an auditor to gather, sufficient information for each suchcreator to securely and reliably receive payments from distributor Cbased on usage activities related to users and/or user/distributorsenabled by distributor C. Furthermore, distributor C may negotiate usingVDE with some or all of such creators to enable a model in whichdistributor C provides overall control information for the entirecontainer based on a “uniform” fee (e.g. calculated per month, peraccess, from a combined model, etc.) charged to users and/oruser/distributors, while preserving the models of each such creator withrespect to payments due to them by distributor C based on C_(B), C_(C),and/or C_(D), and, for example, resulting from each of their differingmodels for the collection of content usage information and any related(e.g. advertising) information.

[2497] In this example, distributor B may receive a VDE contentcontainer and associated content control information C_(E) from creatorE as shown in FIG. 83. If C_(E) permits, distributor B may extract aportion of the content in such a container. Distributor B may then, forexample, embed this portion in a container received from distributor Cthat contains an aggregation of VDE objects created by creator B,creator C, and creator D. Depending on the particular restrictionsand/or permissions in the sets of control information received from eachcreator and distributor C, distributor B may, for example, be able toembed such an extracted portion into the container received fromdistributor C as an independent VDE object, or directly into content of“in place” objects from creator B, creator C, and/or creator D.Alternatively, or in addition, distributor B may, if permitted by C_(E),choose to distribute such an extracted portion of content as anindependent VDE object.

[2498] User B may, in this example, receive a VDE content container fromdistributor C that is comprised of VDE objects created by creator B,creator C, and creator D. In addition, user B may receive a VDE contentcontainer from distributor B that contains the same content created bycreator B, creator C, and creator D in addition to one or moreextracted/embedded portions of content created by creator E. User B maybase decisions concerning which of such containers they choose to use(including which embedded containers she may wish to use), and underwhich circumstances, based on, for example, the character of suchextracted/embedded portions (e.g. multimedia presentations illustratingpotential areas of interest in the remainder of the content, commentaryexplaining and/or expositing other elements of content, related works,improved application software delivered as an element of content, etc.);the quality, utility, and/or price (or other attributes of controlinformation) of such portions; and other considerations whichdistinguish the containers and/or content control information received,in this example, from distributor B and distributor C.

[2499] User B may receive content control information from distributor Bfor such a VDE content container that permits user B to add and/ormodify content contained therein. User B may, for example, desire anability to annotate content in such a container using a VDE aware wordprocessor or other application(s). If permitted by senior controlinformation, some or all of the content may be available to user B formodification and/or additions. In this case, user B is acting as a VDEcreator for added and/or modified content. User B may, for example,provide new control information for such content, or may be required (ordesire to) make use of existing control information (or controlinformation included by senior members of a chain of handling for thispurpose) to manage such content (based on control information related tosuch a container and/or contained objects).

[2500] In this example, VDE 100 has been used to enable an environmentincluding, for example, content distribution, redistribution,aggregation (extracting and/or embedding), reaggregation, modification,and usage. The environment in this example allows competitive models inwhich both control information and content may be negotiated for andhave different particulars based on the chain of handling through whichcontrol information and/or content has been passed. Furthermore, theenvironment in this example permits content to be added to, and/ormodified by, VDE participants receiving control information that enablessuch activities.

[2501] Example—Content Distribution Through a Content VDE Chain ofHandling

[2502]FIG. 84 reflects certain aspects of a relatively simple model 3400of VDE content distribution involving several categories of VDEparticipants. In this instance, and for simplicity of referencepurposes, various portions of content are represented as discrete itemsin the form of VDE content container objects. One or more of suchcontent portions may also be integrated together in a single object andmay (as may the contents of any VDE content container object if allowedby content control information) be extracted in whole or part by a user.In this example, publishers of historical/educational multimedia contenthave created VDE content containers through the use of content objectsavailable from three content resources:

[2503] a Video Library 3402 product available to Publishers on opticaldiscs and containing video clip VDE objects representing varioushistorical situations,

[2504] an Internet Repository 3404 which stores history information textand picture resources in VDE objects which are available for downloadingto Publishers and other users, and

[2505] an Audio Library 3406, also available on optical discs, andcontaining various pieces of musical performances and vocal performances(for example, historical narrations) which can be used alone or toaccompany other educational historical materials.

[2506] The information provided in library 3402, repository 3404, andlibrary 3406 may be provided to different publishers 3408(a), 3408(b), .. . , 3408(n). Publishers 3408 may, in turn, provide some or all of theinformation they obtain to end users 3410.

[2507] In this example, the Video Library 3402 control informationallows publishers to extract objects from the Video Library productcontainer and content control information enabling use of each extractedobject during a calendar year if the object has a license cost of $50 orless, and is shorter than 45 minutes in duration, and 20,000 copies ofeach of any other extracted objects, and further requires all videoobjects to be VDE fingerprinted upon decryption. The Audio Library 3404has established similar controls that match its business model. TheInternet Repository 3406 VDE containerizes, including encrypts, selectedobject content as it streams out of the Repository in response to anonline, user request to download an object. The Repository 3406 mayfingerprint the identification of the receiving VDE installation intoits content prior to encryption and communication to a publisher, andmay further require user identification fingerprinting of their contentwhen decrypted by said Publisher or other content user.

[2508] The Publishers 3408 in this example have selected, under termsand conditions VDE negotiated (or otherwise agreed to) with theproviding resources, various content pieces which they combine togetherto form their VDE object container products for their teacher customers.Publisher 3408(A) has combined video objects extracted from the VideoLibrary 3402 (as indicated by circles), text and image objects extractedfrom the Internet Repository 3404 (indicated by diamonds), and onemusical piece and one historical narration extracted from the AudioLibrary 3406 (as indicated by rectangles). Publisher 3408(B) hasextracted a similar array of objects to be combined into his product,and has further added graphical elements (indicated by a hexagon)created by Publisher 3408(B) to enhance the product. Publisher 3408(C)has also created a product by combining objects from the InternetRepository 3404 and the Audio Library 3406. In this example, allpublisher products are delivered, on their respective optical discs, inthe form of VDE content container objects with embedded objects, to amodern high school for installation on the high school's computernetwork.

[2509] In this particular example, End-Users 3410 are teachers who usetheir VDE node's secure subsystems to access the VDE installation ontheir high school server that supports the publishers' products (in analternative example, the high school may maintain only a server basedVDE installation). These teachers license the VDE products from one ormore of the publishers and extract desired objects from the VDE productcontent containers and either download the extracted VDE content in theform of VDE content containers for storage on their classroom computersand/or as appropriate and/or efficient. The teachers may store extractedcontent in the form of VDE content containers on server mass storage(and/or if desired and available to an end-user, and further accordingto acceptable pricing and/or other terms and conditions and/or seniorcontent control information, they may store extracted information in“clear” unencrypted form on their nodes' and/or server storage means).This allows the teachers to play, and/or otherwise use, the selectedportions of said publishers' products, and as shown in two instances inthis example, add further teacher and/or student created content to saidobjects. End-user 3410(2), for example, has selected a video piece 1received from Publisher A, who received said object from the VideoLibrary. End-user 3410(3) has also received a video piece 3 from thesame Publisher 3408(A) wherein said piece was also available to her fromPublisher 3408(B), but perhaps under not as favorable terms andconditions (such as a support consultation telephone line). In addition,end-user 3410(3) has received an audio historical narration fromPublisher 3408(B) which corresponds to the content of historicalreference piece 7. End-user 3410(3) has also received a correspondinghistorical reference piece 7 (a book) from publisher 3408(2) whoreceived said book from the Internet Repository 3404. In this instance,perhaps publisher 3408(2) charged less for said book because end-user3410(3) has also licensed historical reference piece 7 from him, ratherthan publisher 3408(1), who also carried the same book. End-user3410(3), as a teacher, has selected the items she considers mostappropriate for her classes and, through use of VDE, has been able toflexibly extract such items from resources available to her (in thisinstance, extracting objects from various optical products provided bypublishers and available on the local high school network server).

[2510] Example—Distribution of Content Control Information Within anOrganization

[2511]FIG. 85 shows two VDE content containers, Container 300(A) andContainer 300(B), that have been distributed to a VDE ClientAdministrator 3450 in a large organization. As shown in the figure,Container 300(A) and Container 300(B), as they arrive at thecorporation, carry certain control information specifying availableusage rights for the organization. As can be further seen in FIG. 85,the client administrator 3450 has distributed certain subsets of theserights to certain department administrators 3452 of her organization,such as Sales and Marketing Administrator 3452(1), PlanningAdministrator 3452(2), and Research and Development Administrator3452(k). In each instance, the Client Administrator 3450 has decidedwhich usage options and how much budget should be made available to eachdepartment.

[2512]FIG. 85 is a simplified example and, for example, the ClientAdministrator 3450 could have added farther VDE controls created byherself and/or modified and/or deleted in place controls (if allowed bysenior content control information) and/or (if allowed by controlinformation) she could have further divided the available monetarybudget (or other budgets) among specific usage activities. In thisexample, departmental administrators have the same rights to determinethe rights of departmental end-users as the client administrator has inregard to departments. In addition, in this example (but not shown inFIG. 85) the client administrator 3450 and/or content provider(s) mayalso determine certain control information which must directly control(including providing rights related to) end-user content usage and/orthe consequences of said usage for all or certain classes of end-users.In the example shown in FIG. 85, there are only three levels of VDEparticipants within the organization:

[2513] a Client Administrator 3450,

[2514] department administrators 3452, and

[2515] end-users 3454.

[2516] In other examples, VDE will support many levels of VDEadministration (including overlapping groups) within an organization(e.g., division, department, project, network, group, end-users, etc).In addition, administrators in a VDE model may also themselves be VDEcontent users.

[2517] Within an organization, VDE installations may be at each end-user3454 node, only on servers or other multiple user computers or otherelectronic appliances, or there may be a mixed environment.Determination as to the mix of VDE server and/or node usage may be basedon organization and/or content provider security, performance, costoverhead, or other considerations.

[2518] In this example, communications between VDE participants in FIG.85 employs VDE secure communication techniques between VDE securesubsystems supporting PPEs and other VDE secure system components ateach VDE installation within the organization.

[2519] Example—Another Content Distribution Example

[2520] Creators of VDE protected content may interact with other VDEparticipants in many different ways. A VDE creator 102 may, for example,distribute content and/or content control information directly to users,distribute content and/or content control information to commercialcontent repositories, distribute content and/or content controlinformation to corporate content repositories, and/or distribute contentand/or content control information to other VDE participants. If acreator 102 does not interact directly with all users of her content,she may transmit distribution permissions to other VDE participants thatpermit such participants to further distribute content and/or contentcontrol information. She may also allow further distribution of VDEcontent and/or content control information by, for example, notrestricting redistribution of control information, or allowing a VDEparticipant to act as a “conduit” for one or more permissions recordsthat can be passed along to another party, wherein said permissionsrecord provides for including the identification of the first receivingparty and/or the second receiving party.

[2521]FIG. 86 shows one possible arrangement of VDE participants. Inthis example, creator 102 may employ one or more application softwareprograms and one or more VDE secure subsystems to place unencryptedcontent into VDE protected form (i.e., into one or more VDE contentcontainers). In addition, creator 102 may produce one or moredistribution permissions 3502 and/or usage permissions 3500 as an aspectof control information associated with such VDE protected content. Suchdistribution and/or usage permissions 3500, 3502 may be the same (e.g.,all distribution permissions may have substantively all the samecharacteristics), or they may differ based on the category and/or classof participant for whom they are produced, the circumstances under whichthey are requested and/or transmitted, changing content control modelsof either creator 102 or a recipient, etc.

[2522] In this example, creator 102 transmits (e.g., over a network, viabroadcast, and/or through transfer of physical media) VDE protectedcontent to user 112 a, user 112 b, and/or user 112 c. In addition,creator 102 transmits, using VDE secure communications techniques, usagepermissions to such users. User 112 a, user 112 b, and user 112 c mayuse such VDE protected content within the restrictions of controlinformation specified by usage permissions received from creator 102. Inthis case, creator 102 may, for example, manage all aspects of suchusers activities related to VDE protected content transmitted to them bycreator 102. Alternatively, creator 102 may, for example, includereferences to control information that must be available to users thatis not provided by creator 102 (e.g., component assemblies managed byanother party).

[2523] Commercial content repository 200 g, in this example, may receiveVDE protected (or otherwise securely delivered) content anddistribution, permissions and/or other content usage control informationfrom creator 102. Commercial content repository 200 g may store contentsecurely such that users may obtain such, when any required conditionsare met, content from the repository 200 g. The distribution permissions3502 may, for example, permit commercial content repository 200 g tocreate redistribution permissions and/or usage permissions 3500, 3502using a VDE protected subsystem within certain restrictions described incontent control information received from creator 102 (e.g., not toexceed a certain number of copies, requiring certain payments bycommercial content repository 200 g to creator 102, requiring recipientsof such permissions to meet certain reporting requirements related tocontent usage information, etc.). Such content control information maybe stored at the repository installation and be applied to unencryptedcontent as it is transmitted from said repository in response to a userrequest, wherein said content is placed into a VDE container as a stepin a secure process of communicating such content to a user.Redistribution permissions may, for example, permit a recipient of suchpermissions to create a certain number of usage permissions withincertain restrictions (e.g., only to members of the same household,business other organization, etc.). Repository 200 g may, for example,be required by control information received from creator 102 to gatherand report content usage information from all VDE participants to whomthe repository has distributed permissions.

[2524] In this example, power user 112d may receive VDE protectedcontent and redistribution permissions from commercial contentrepository 200 g using the desktop computer 3504. Power user 112 d may,for example, then use application software in conjunction with a VDEsecure subsystem of such desktop computer 3504 in order to produce usagepermissions for the desktop computer 3504, laptop computer 3506 and/orsettop appliance 3508 (assuming redistribution permissions received fromcommercial content repository 200 g permit such activities). Ifpermitted by senior control information (for example, from creator 102as may be modified by the repository 200 g), power user 112 d may addher own restrictions to such usage permissions (e.g., restrictingcertain members of power user 112 d's household using the settopappliance to certain times of day, amounts of usage, etc. based on theiruser identification information). Power user 112 d may then transmitsuch VDE protected content and usage permissions to the laptop computer3506 and the settop appliance 3508 using VDE secure communicationstechniques. In this case, power user 112 d has redistributed permissionsfrom the desktop computer 3504 to the settop appliance 3508 and thelaptop computer 3506, and periodically the settop appliance and thelaptop computer may be required to report content usage information tothe desktop computer, which in turn may aggregate, and/or otherwiseprocess, and report user usage information to the repository 200 g.

[2525] User 112 e and/or user 112 f may receive usage permissions andVDE protected content from commercial content repository 200 g. Theseusers may be able to use such content in ways authorized by such usageinformation. In contrast to power user 112 d, these users may not haverequested and/or received redistribution permissions from the repository200 g. In this case, these users may still be able to transfer some orall usage rights to another electronic appliance 600, and/or they may bepermitted to move some of their rights to another electronic appliance,if such transferring and/or moving is permitted by the usage permissionsreceived from the repository 200 g. In this case, such other appliancesmay be able to report usage information directly to the repository 200g.

[2526] In this example, corporate content repository 702 withincorporation 700 may receive VDE protected content and distributionpermissions from creator 102. The distribution permissions received bycorporate repository 702 may, for example, include restrictions thatlimit repository 702 to distribution activities within corporation 700.

[2527] The repository 702 may, for example, employ an automated systemoperating in conjunction with a VDE secure subsystem to receive and/ortransmit VDE protected content, and/or redistribution and/or usagepermissions. In this case, an automated system may, for example, rely oncriteria defined by corporate policies, departmental policies, and/oruser preferences to determine the character of permissions and/orcontent delivered to various parties (corporation groups and/orindividuals) within corporation 700. Such a system may, for example,automatically produce redistribution permissions for a departmentalcontent repository 704 in response to corporation 700 receivingdistribution permissions from creator 102, and/or produce usagepermissions for user 112 j and/or user 112 k.

[2528] The departmental repository 704 may automatically produce usagepermissions for user 112 g, user 112 h, and/or user 112 i. Such usersmay access content from the corporate content repository 702, yetreceive usage permissions from departmental repository 704. In thiscase, user 112 g, user 112 h, and/or user 112 i may receive usagepermissions from departmental repository 704 that incorporatedepartmental restrictions in addition to restrictions imposed by seniorcontrol information (in this example, from creator 102, as may bemodified by corporate repository 702, as may be further modified bydepartmental repository 704, that reflect a VDE extended agreementincorporating commercial requirements of creator 102 and corporation 700in addition to corporate and/or departmental policies and agreementswith corporate personnel of corporation 700).

[2529] Example—“Virtual Silicon Container”

[2530] As discussed above, VDE in one example provides a “virtualsilicon container” (“virtual black box”) in that several differentinstances of SPU 500 may securely communicate together to provide anoverall secure hardware environment that “virtually” exists at multiplelocations and multiple electronic appliances 600. FIG. 87 shows onemodel 3600 of a virtual silicon container. This virtual container model3600 includes a content creator 102, a content distributor 106, one ormore content redistributors 106 a, one or more client administrators700, one or more client users 3602, and one or more clearinghouses 116.Each of these various VDE participants has an electronic appliance 600including a protected processing environment 655 that may comprise, atleast in part, a silicon-based semiconductor hardware element secureprocessing unit 500. The various SPUs 500 each encapsulate a part of thevirtual distribution environment, and thus, together form the virtualsilicon container 3600.

[2531] Example—Testing/Examinations

[2532] A scheduled SAT examination for high school seniors is preparedby the Educational Testing Service. The examination is placed in a VDEcontainer for scheduled release on Nov. 15, 1994 at 1:00 PM EasternStandard time. The SAT prepares one copy of the container for eachschool or other location which will conduct the examination. The schoolor other location (“test site”) will be provided with a distributedexamination container securely containing the VDE identification for the“administration” electronic appliance and/or test administrator at thetest site (such as, a testing organization) and a budget enabling, forexample, the creation of 200 test VDE content containers. Each containercreated at the test site may have a permissions record containing secureidentification information for each electronic appliance 600, on thetest site's network, that will be used by a test taker, as well as, forexample, an identification for the student who will take the test. Thestudent identification could, for example, be in the form of a securePIN password which is entered by the student prior to taking the test (atest monitor or administrator might verify the student identification byentering in a PIN password). Of course, identification might take thefirm of automated voice recognition, handwriting recognition (signaturerecognition), fingerprint information, eye recognition, or similar oneor more recognition forms which may be used either to confirm theidentity of the test taker (and/or test monitor/administrator) and/ormay be stored with the test results in a VDE container or the like or ina location pointed to by certain container information. Thisidentification may be stored in encrypted or unencrypted form. If storedin encrypted or otherwise protected form, certain summary information,such as error correction information, may be stored with theidentification information to authenticate the associated test ascorresponding to the identification.

[2533] As the student takes the test using the computer terminal, theanswers selected may be immediately securely stored (but may be changedby the student during the test session). Upon the completion of thetest, the student's answers, along with a reference to the test, aresecurely stored in a VDE reporting object which is passed along to thenetwork to the test administrator and the administration electronicappliance 600. All test objects for all students could then be placed ina VDE object 300 for communication to the Educational Testing Service,along with whatever other relevant information (which may also besecured by VDE 100), including summary information giving average andmean scores, and other information that might be desirable to summarizeand/or act as an authentication of the test objects sent. For example,certain information might be sent separately from each student summaryobject containing information which helps validate the object as an“authentic” test object.

[2534] Applying VDE to testing scenarios would largely eliminatecheating resulting from access to tests prior to testing (normally thetests are stolen from a teacher or test administrator). At ETS,individuals who have access to tests could be limited to only a portionof the test to eliminate the risk of the theft of a “whole” test.Employing VDE would also ensure against processing errors or othermanipulation of test answers, since absolutely authentic test resultscan be archived for a reasonable period of time.

[2535] Overall, employing VDE 100 for electronic testing will enable thebenefits of electronic testing to be provided without the substantialrisks associated with electronic storing, communicating, and processingof test materials and testing results. Electronic testing will provideenormous efficiency improvements, significantly lowering the cost ofconducting and processing tests by eliminating printing, shipping,handling, and human processing of tests. At the same time, electronictesting will allow users to receive a copy (encrypted or unencrypted) oftheir test results when they leave the test sessions. This will helpprotect the tested individual against lost of, or improperly processed,test results. Electronic testing employing VDE 100 may also ensure thattiming related variables of testing (for example precise starting,duration, and stopping times) can be reliably managed. And, of course,proper use of VDE 100 for the testing process can prevent improperaccess to test contents prior to testing and ensure that test taking isproperly audited and authenticated, that is which person took whichtest, at which time, on which electronic appliance, at which location.Retesting due to lost, stolen, improperly timed, or other variables canbe avoided or eliminated.

[2536] VDE assisted testing may, of course, be employed for manydifferent applications including secure identification of individualsfor security/authentication purposes, for employment (e.g. applying forjobs) applications, and for a full range of evaluation testing. Forexample, an airline pilot, or a truck, train, or bus driver might take atest immediately prior to departure or during travel, with the testevaluating alertness to test for fatigue, drug use, etc. A certain testmay have a different order and/or combination of test activities eachtime, or each group of times, the test is taken. The test or a mastertest might be stored in a VDE container (the order of, and which, testquestions might be determined by a process executed securely within anPPE 650). The test responses may be encrypted as they occur and eitherlocally stored for aggregated (or other test result) transmission ordynamically transmitted (for example, to a central test administrationcomputer). If the test taker “flunks” the test, perhaps he or she isthen prevented from operating the vehicle, either by a local PPE 650issuing control instructions to that effect on some portion of thevehicle's electronic control system or a local PPE failing to decrypt orotherwise provide certain key information required for vehicleoperation.

[2537] Example—Appliance Rental

[2538] Through use of the present invention, electronic appliances canbe “leased” or otherwise provided to customers who, rather thanpurchasing a given appliance for unlimited usage, may acquire theappliance (such as a VCR, television, microwave oven, etc.) and becharged according to one or more aspects of use. For example, the chargefor a microwave might be for each time it is used to prepare an itemand/or for the duration of time used. A telephone jack could beattached, either consistently or periodically, to an inexpensive modemoperatively attached or within the microwave (the modem mightalternatively be located at a location which services a plurality ofitems and/or functions—such as burglar alarm, light and/or heatcontrol). Alternatively, such appliances may make use of a networkformed by the power cables in a building to transmit and receivesignals.

[2539] At a periodic interval, usage information (in summary form and/ordetailed) could be automatically sent to a remote information utilitythat collects information on appliance usage (the utility might servicea certain brand, a certain type of appliance, and/or a collection ofbrands and/or types). The usage information would be sent in VDE form(e.g. as a VDE object 300). The information utility might thendistribute information to financial clearinghouse(s) if it did notitself perform the billing function, or the information “belonging” toeach appliance manufacturer and/or lessor (retailer) might be sent tothem or to their agents. In this way a new industry would be enabled ofleased usage of appliances where the leases might be analogous to carleasing.

[2540] With VDE installed, appliances could also be managed by secureidentification (PIN, voice or signature recognition, etc.). This mightbe required each time a unit is used, or on some periodic basis. Failureto use the secure identification or use it on a timely basis coulddisable an appliance if a PPE 650 issued one or more instructions (orfailed to decrypt or otherwise provide certain information critical toappliance operation) that prevented use of a portion or all of theappliance's functions. This feature would greatly reduce thedesirability of stealing an electronic appliance. A further, allied useof VDE is the “registration” of a VDE secure subsystem in a givenappliance with a VDE secure subsystem at some control location in a homeor business. This control location might also be responsible for VDEremote communications and/or centralized administration (including, forexample, restricting your children from viewing R rated movies either ontelevision or videocassettes through the recognition of data indicatingthat a given movie, song, channel, game, etc. was R rated and allowing aparent to restrict viewing or listening). Such a control location may,for example, also gather information on consumption of water, gas,electricity, telephone usage, etc. (either through use of PPEs 650integrated in control means for measuring and/or controlling suchconsumption, or through one or more signals generated by non-VDE systemsand delivered to a VDE secure subsystem, for example, for processing,usage control (e.g. usage limiting), and/or billing), transmit suchinformation to one or more utilities, pay for such consumption using VDEsecured electronic currency and/or credit, etc.

[2541] In addition, one or more budgets for usage could be managed byVDE which would prevent improper, excessive use of a certain, leasedappliance, that might, for example lead to failure of the appliance,such as making far more copies using a photocopier than specified by theduty cycle. Such improper use could result in a message, for example ona display panel or television screen, or in the form of a communicationfrom a central clearinghouse, that the user should upgrade to a morerobust model.

[2542] While the invention has been described in connection with what ispresently considered to be the most practical and preferred embodiment,it is to be understood that the invention is not to be limited to thedisclosed embodiment, but on the contrary, is intended to cover variousmodifications and equivalent arrangements included within the spirit andscope of the appended claims.

We claim:
 1. A rights management appliance including: a user inputdevice, a user display device, at least one processor, and at least oneelement defining a protected processing environment, characterized inthat the protected processing environment stores and uses permissions,methods, keys, programs and/or other information to electronicallymanage rights.
 2. In a rights management appliance including: a userinput device, a user display device, at least one processor, and atleast one element defining a protected processing environment, a methodof operating the appliance characterized by the step of storing andusing permissions, methods, keys, programs and/or other information toelectronically manage rights.
 3. A rights management appliance includingat least one processor element at least in part defining a protectedprocessing environment, characterized in that the protected processingenvironment stores and uses permissions, methods, keys, programs and/orother information to electronically manage rights.
 4. In a rightsmanagement appliance including at least one processor element at leastin part defining a protected processing environment, a method comprisingstoring and using permissions, methods, keys, programs and/or otherinformation to electronically manage rights.
 5. An electronic appliancearrangement containing at least one secure processing unit and at leastone secure database operatively connected to at least one of said secureprocessing unit(s), said arrangement including means to monitor usage ofat least one aspect of appliance usage and control said usage based atleast in part upon protected appliance usage control information.
 6. Inan electronic appliance arrangement containing at least one secureprocessing unit and at least one secure database operatively connectedto at least one of said secure processing unit(s), a methodcharacterized by the steps of monitoring usage of at least one aspect ofappliance usage and controlling said usage based at least in part uponprotected appliance usage control information.
 7. An electronicappliance arrangement containing a protected processing environment andat least one secure database operatively connected to said protectedprocessing environment, said arrangement including means to monitorusage of at least one aspect of an amount of appliance usage and controlsaid usage based at least in part upon protected appliance usage controlinformation processed at least in part through use of said protectedprocessing environment.
 8. In an electronic appliance arrangementcontaining a protected processing environment and at least one securedatabase operatively connected to said protected processing environment,a method characterized by the steps of monitoring usage of at least oneaspect of appliance usage and controlling said usage based at least inpart upon protected appliance usage control information processed atleast in part through use of said protected processing environment. 9.An electronic appliance arrangement containing one or more CPUs whereinat least one of the CPUs incorporates an integrated secure processingunit, said arrangement storing protected appliance usage controlinformation designed to be securely processed by said integrated secureprocessing unit.
 10. In an electronic appliance arrangement containingone or more CPUs wherein at least one of the CPUs incorporates anintegrated secure processing unit, a method including the step ofstoring and securely processing protected modular component applianceusage control information with said integrated secure processing unit.11. A method of compromising a distributed electronic rights managementsystem comprising plural nodes having protected processing environments,characterized by the following steps: (a) exposing a certificationprivate key, (b) passing at least one challenge/response protocol and/orexposing at least one external communication key based at least in parton the key exposed by the exposing step, (c) creating a processingenvironment based at least in part on steps (a) and (b), andparticipating in distributed rights management using the processingenvironment created by step (c).
 12. A processing environment forcompromising a distributed electronic rights management systemcomprising plural nodes having protected processing environments,characterized by the following: protocol passing means including anexposed certification private key for passing at least onechallenge/response protocol, means coupled to the protocol passing meansfor at least one of (a) defeating an initialization challenge/responsesecurity, and/or (b) exposing external communication keys, and meanscoupled to the security detecting means for participating in distributedrights management.
 13. A method of compromising a distributed electronicrights management system comprising plural nodes having associatedprotected processing environments, characterized by the steps of:compromising the permissions record of an electronic container, andusing the compromised permissions record to access and/or use electronicinformation.
 14. A system for compromising a distributed electronicrights management system comprising plural nodes having associatedprotected processing environments, characterized by means for using acompromised permissions record of an electronic container for accessingand/or using electronic information.
 15. A method of tampering with aprotected processing environment characterized by the steps of:discovering at least one system-wide key, and using the key to obtainaccess to content and/or administrative information withoutauthorization.
 16. An arrangement including means for using at least onecompromised system-wide key to decrypt and compromise content and/oradministrative information of a protected processing environment withoutauthorization.
 17. A combination general and secure processingcomputation element comprising: a central processing unit; at least onesecure resource; and a secure mode interface switch coupled between acentrla processing unit and the secure resource, the switch operablealternately in a secure mode and in a non secure mode, the switchblocking access by a central processing unit to the secure resourceexcept when the switch is operating in the secure mode.
 18. A secureprinting method comprising: downloading a decryption program to anintelligent printer; sending an encrypted print stream to the printer;decrypting the encrypted print stream within the printer using thedecryption program; and destroying the downloaded decryption program.